- changed title to ImmutableColumnCollection creates a separate _col_set on getstate
- changed component to sql
ImmutableColumnCollection creates a separate _col_set on getstate
Testcase: httpshttps://gist.github.com/anonymous/e343baf76747d104a15e
If you comment out the pickling line, it works. Otherwise, it fails with
sqlalchemy.exc.ArgumentError: Could not locate any simple equality expressions involving locally mapped foreign key columns for primary join condition 'server.id = site.server' on relationship Site.server_. Ensure that referencing columns are associated with a ForeignKey or ForeignKeyConstraint, or are annotated in the join condition with the foreign() annotation. To allow comparison operators other than '==', the relationship can be marked as viewonly=True.
The only difference it makes is whether or not the metadata has been pickled.
You can also make it work by commenting out the class declarations but I thought automap was supposed to permit you to gracefully override reflected metadata, even if it's been pickled.
Python 2.7.11 SQLAlchemy==1.0.10 PyMySQL==0.6.7
Thanks, Jeff
Comments (7)
-
repo owner -
repo owner - changed milestone to 1.1
-
reporter Hi Mike,
I added the workaround to my project and it works perfectly, I can now load my serialized metadata. I'm all set for now.
Thanks so much for the quick response! Jeff
-
repo owner - changed milestone to 1.0.xx
I do think I can make a fix that works this out for 1.0, basically not using the column set anymore as it doesn't seem to be needed
-
repo owner - changed status to resolved
- rework ColumnCollection to no longer persist "all_col_set"; we don't need this collection except in the extend/update uses where we create it ad-hoc. simplifies pickling. Compatibility with 1.0 should be OK as ColumnColleciton uses getstate in any case and the setstate contract hasn't changed.
- Fixed bug in :class:
.Table
metadata construct which appeared around the 0.9 series where adding columns to a :class:.Table
that was unpickled would fail to correctly establish the :class:.Column
within the 'c' collection, leading to issues in areas such as ORM configuration. This could impact use cases such asextend_existing
and others. fixes#3632
→ <<cset 8163de4cc9e0>>
-
repo owner - rework ColumnCollection to no longer persist "all_col_set"; we don't need this collection except in the extend/update uses where we create it ad-hoc. simplifies pickling. Compatibility with 1.0 should be OK as ColumnColleciton uses getstate in any case and the setstate contract hasn't changed.
- Fixed bug in :class:
.Table
metadata construct which appeared around the 0.9 series where adding columns to a :class:.Table
that was unpickled would fail to correctly establish the :class:.Column
within the 'c' collection, leading to issues in areas such as ORM configuration. This could impact use cases such asextend_existing
and others. fixes#3632
(cherry picked from commit 8163de4cc9e01460d3476b9fb3ed14a5b3e70bae)
→ <<cset c7ddf26dd22a>>
-
repo owner Also note the adjustment to the patch in 5742e321b261c0c1303835b80 and b11bfd5b0c7262bd207bbaf6be2d1b025119abe7, "column.key" is not sufficient here so we use an ad-hoc set
- Log in to comment
here's simplification one:
then here's more specifically:
and the fix is not 100% backwards compatible, as it requires changing the pickle format of either ColumnCollection or ImmutableColumnCollection. Here's the better version:
a workaround for your immediate case is:
can you wait til 1.1? it won't be for months.