python/python-alembic
SHA256
15
0
Fork 0
forked from pool/python-alembic
Code Pull Requests Activity

Accepting request 284207 from home:tbechtold:branches:devel:languages:python

Browse Source 
New upstream bugfix release

OBS-URL: https://build.opensuse.org/request/show/284207
OBS-URL: https://build.opensuse.org/package/show/devel:languages:python/python-alembic?expand=0&rev=34
This commit is contained in:
Denisart Benjamin
2015-02-05 15:23:11 +00:00
committed by Git OBS Bridge
parent f084d24ddb
commit 5b067eb02b
4 changed files with 37 additions and 5 deletions
Download Patch File Download Diff File Expand all files Collapse all files

32
python-alembic.changes
View File

@@ -1,3 +1,35 @@
-------------------------------------------------------------------
Thu Feb 5 15:04:20 UTC 2015 - tbechtold@suse.com
- update to 0.7.4:
* Repaired issue where a server default specified without text()
that represented a numeric or floating point (e.g. with decimal
places) value would fail in the Postgresql-specific check for
“compare server default”; as PG accepts the value with quotes
in the table specification, it’s still valid. Pull request
courtesy Dimitris Theodorou.
* The rendering of a ForeignKeyConstraint will now ensure that
the names of the source and target columns are the database-side
name of each column, and not the value of the .key attribute as
may be set only on the Python side. This is because Alembic
generates the DDL for constraints as standalone objects without
the need to actually refer to an in-Python Table object, so
there’s no step that would resolve these Python-only key names
to database column names.
* Fixed bug in foreign key autogenerate where if the in-Python
table used custom column keys (e.g. using the key='foo' kwarg
to Column), the comparison of existing foreign keys to those
specified in the metadata would fail, as the reflected table
would not have these keys available which to match up. Foreign
key comparison for autogenerate now ensures it’s looking at
the database-side names of the columns in all cases; this
matches the same functionality within unique constraints and
indexes.
* Fixed issue in autogenerate type rendering where types that
belong to modules that have the name “sqlalchemy” in them would
be mistaken as being part of the sqlalchemy. namespace. Pull
req courtesy Bartosz Burclaf.
-------------------------------------------------------------------
Mon Jan 5 10:19:27 UTC 2015 - dmueller@suse.com