Re: [sqlalchemy] SAWarnings when using history_meta.py versioning and Inheritance.
Hi Michael, I quite agree that child entities don't need their own copy of the changed attribute, but this is also the way that the version attribute is handled. (ie: both parent and child entities have their own copy of version) Is there any way we can fix the both of them ? As for the option to remove the changed attribute... Well, I'm the one who suggested its addition and submitted the pull request :) Thanks, JP On Friday, 17 October 2014 16:05:15 UTC-4, Michael Bayer wrote: On Oct 17, 2014, at 3:50 PM, JPLaverdure jp.lav...@gmail.com javascript: wrote: Hi Michael, My bad, they do indeed only show up on mapping... which takes place when my pyramid app instantiates. Sorry for the confusion :) Still, they could be unnerving for someone deploying the app. Any way to not have these show up ? I did look into version_meta.py and tried to make some tweaks when I saw anything having to do with the version atribute.. But to no avail. Your help is greatly appreciated ! it’s not clear why a class that inherits from another needs a separate “changed” column in any case. The recipe indicates on line 68 this column is optional so I’d remove it, or just make it conditional if “super_mapper” is not present to have it only on the base table. or maybe just map it differently, or not at all, down where it calls mapper(): m = mapper( versioned_cls, table, inherits=super_history_mapper, polymorphic_on=polymorphic_on, polymorphic_identity=local_mapper.polymorphic_identity, exclude_columns=[‘changed’] ) JP On Friday, 17 October 2014 14:52:22 UTC-4, JPLaverdure wrote: Hello, It seems a number of SAWarnings are being thrown whenever I instantiate Versioned objects which make use of inheritance: SAWarning: Implicitly combining column container_history.changed with column barcoded_container_history.changed under attribute 'changed'. Please configure one or more attributes for these same-named columns explicitly. prop = self._property_from_column(key, prop) Unfortunately, since these objects are instantiated auto-magically by the Versioned mixin class, I can't see a way to make these go away or address the issue. I tried looking into the history_meta.py source and cannot understand why this same warning is not being thrown for the version attribute. Anyone has an idea ? Thanks ! JP -- You received this message because you are subscribed to the Google Groups sqlalchemy group. To unsubscribe from this group and stop receiving emails from it, send an email to sqlalchemy+...@googlegroups.com javascript:. To post to this group, send email to sqlal...@googlegroups.com javascript:. Visit this group at http://groups.google.com/group/sqlalchemy. For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups sqlalchemy group. To unsubscribe from this group and stop receiving emails from it, send an email to sqlalchemy+unsubscr...@googlegroups.com. To post to this group, send email to sqlalchemy@googlegroups.com. Visit this group at http://groups.google.com/group/sqlalchemy. For more options, visit https://groups.google.com/d/optout.
Re: [sqlalchemy] SAWarnings when using history_meta.py versioning and Inheritance.
“version” is part of the primary key and is FK’ed to the superclass table, so the warning isn’t generated for that one. it wouldn’t be appropriate for a datetime “changed” to have a foreign key. IMO it only needs to be on the base table. On Oct 21, 2014, at 2:35 PM, JPLaverdure jp.laverd...@gmail.com wrote: Hi Michael, I quite agree that child entities don't need their own copy of the changed attribute, but this is also the way that the version attribute is handled. (ie: both parent and child entities have their own copy of version) Is there any way we can fix the both of them ? As for the option to remove the changed attribute... Well, I'm the one who suggested its addition and submitted the pull request :) Thanks, JP On Friday, 17 October 2014 16:05:15 UTC-4, Michael Bayer wrote: On Oct 17, 2014, at 3:50 PM, JPLaverdure jp.lav...@gmail.com javascript: wrote: Hi Michael, My bad, they do indeed only show up on mapping... which takes place when my pyramid app instantiates. Sorry for the confusion :) Still, they could be unnerving for someone deploying the app. Any way to not have these show up ? I did look into version_meta.py and tried to make some tweaks when I saw anything having to do with the version atribute.. But to no avail. Your help is greatly appreciated ! it’s not clear why a class that inherits from another needs a separate “changed” column in any case. The recipe indicates on line 68 this column is optional so I’d remove it, or just make it conditional if “super_mapper” is not present to have it only on the base table. or maybe just map it differently, or not at all, down where it calls mapper(): m = mapper( versioned_cls, table, inherits=super_history_mapper, polymorphic_on=polymorphic_on, polymorphic_identity=local_mapper.polymorphic_identity, exclude_columns=[‘changed’] ) JP On Friday, 17 October 2014 14:52:22 UTC-4, JPLaverdure wrote: Hello, It seems a number of SAWarnings are being thrown whenever I instantiate Versioned objects which make use of inheritance: SAWarning: Implicitly combining column container_history.changed with column barcoded_container_history.changed under attribute 'changed'. Please configure one or more attributes for these same-named columns explicitly. prop = self._property_from_column(key, prop) Unfortunately, since these objects are instantiated auto-magically by the Versioned mixin class, I can't see a way to make these go away or address the issue. I tried looking into the history_meta.py source and cannot understand why this same warning is not being thrown for the version attribute. Anyone has an idea ? Thanks ! JP -- You received this message because you are subscribed to the Google Groups sqlalchemy group. To unsubscribe from this group and stop receiving emails from it, send an email to sqlalchemy+...@googlegroups.com javascript:. To post to this group, send email to sqlal...@googlegroups.com javascript:. Visit this group at http://groups.google.com/group/sqlalchemy http://groups.google.com/group/sqlalchemy. For more options, visit https://groups.google.com/d/optout https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups sqlalchemy group. To unsubscribe from this group and stop receiving emails from it, send an email to sqlalchemy+unsubscr...@googlegroups.com mailto:sqlalchemy+unsubscr...@googlegroups.com. To post to this group, send email to sqlalchemy@googlegroups.com mailto:sqlalchemy@googlegroups.com. Visit this group at http://groups.google.com/group/sqlalchemy http://groups.google.com/group/sqlalchemy. For more options, visit https://groups.google.com/d/optout https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups sqlalchemy group. To unsubscribe from this group and stop receiving emails from it, send an email to sqlalchemy+unsubscr...@googlegroups.com. To post to this group, send email to sqlalchemy@googlegroups.com. Visit this group at http://groups.google.com/group/sqlalchemy. For more options, visit https://groups.google.com/d/optout.
Re: [sqlalchemy] SAWarnings when using history_meta.py versioning and Inheritance.
I fully agree with you and had forgotten that version was part of the primary key. I believe I made the appropriate changes to history_meta.py and will submit a pull request shortly As always, thanks for your help ! JP On Tuesday, 21 October 2014 14:41:15 UTC-4, Michael Bayer wrote: “version” is part of the primary key and is FK’ed to the superclass table, so the warning isn’t generated for that one. it wouldn’t be appropriate for a datetime “changed” to have a foreign key. IMO it only needs to be on the base table. On Oct 21, 2014, at 2:35 PM, JPLaverdure jp.lav...@gmail.com javascript: wrote: Hi Michael, I quite agree that child entities don't need their own copy of the changed attribute, but this is also the way that the version attribute is handled. (ie: both parent and child entities have their own copy of version) Is there any way we can fix the both of them ? As for the option to remove the changed attribute... Well, I'm the one who suggested its addition and submitted the pull request :) Thanks, JP On Friday, 17 October 2014 16:05:15 UTC-4, Michael Bayer wrote: On Oct 17, 2014, at 3:50 PM, JPLaverdure jp.lav...@gmail.com wrote: Hi Michael, My bad, they do indeed only show up on mapping... which takes place when my pyramid app instantiates. Sorry for the confusion :) Still, they could be unnerving for someone deploying the app. Any way to not have these show up ? I did look into version_meta.py and tried to make some tweaks when I saw anything having to do with the version atribute.. But to no avail. Your help is greatly appreciated ! it’s not clear why a class that inherits from another needs a separate “changed” column in any case. The recipe indicates on line 68 this column is optional so I’d remove it, or just make it conditional if “super_mapper” is not present to have it only on the base table. or maybe just map it differently, or not at all, down where it calls mapper(): m = mapper( versioned_cls, table, inherits=super_history_mapper, polymorphic_on=polymorphic_on, polymorphic_identity=local_mapper.polymorphic_identity, exclude_columns=[‘changed’] ) JP On Friday, 17 October 2014 14:52:22 UTC-4, JPLaverdure wrote: Hello, It seems a number of SAWarnings are being thrown whenever I instantiate Versioned objects which make use of inheritance: SAWarning: Implicitly combining column container_history.changed with column barcoded_container_history.changed under attribute 'changed'. Please configure one or more attributes for these same-named columns explicitly. prop = self._property_from_column(key, prop) Unfortunately, since these objects are instantiated auto-magically by the Versioned mixin class, I can't see a way to make these go away or address the issue. I tried looking into the history_meta.py source and cannot understand why this same warning is not being thrown for the version attribute. Anyone has an idea ? Thanks ! JP -- You received this message because you are subscribed to the Google Groups sqlalchemy group. To unsubscribe from this group and stop receiving emails from it, send an email to sqlalchemy+...@googlegroups.com. To post to this group, send email to sqlal...@googlegroups.com. Visit this group at http://groups.google.com/group/sqlalchemy. For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups sqlalchemy group. To unsubscribe from this group and stop receiving emails from it, send an email to sqlalchemy+...@googlegroups.com javascript:. To post to this group, send email to sqlal...@googlegroups.com javascript:. Visit this group at http://groups.google.com/group/sqlalchemy. For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups sqlalchemy group. To unsubscribe from this group and stop receiving emails from it, send an email to sqlalchemy+unsubscr...@googlegroups.com. To post to this group, send email to sqlalchemy@googlegroups.com. Visit this group at http://groups.google.com/group/sqlalchemy. For more options, visit https://groups.google.com/d/optout.
[sqlalchemy] joinedloads under a subqueryload
I've been staring at this for a while, and can't figure out a way to make
the mapper happy:
i have 3 Classes (tables):
* List (list)
* ListItem (list_item)
* ItemType1 (item_type_1)
* ItemType2 (item_type_2)
* ItemType3 (item_type_3)
until now i've been using a joinedload
query = s.query(List)\
.options(
joinedload('list_item'),
joinedload('list_item.item_type_1'),
joinedload('list_item.item_type_2'),
joinedload('list_item.item_type_3'),
)
The performance is starting to become less than optimal, so I wanted to try
creating a subquery for 'list_items', which has the `item_type_1`/2/3
connected to it as a joinedload
the closest I can get is this:
query = s.query(List)\
.options(
subqueryload('list_item')\
.joinedload('item_type_1')
)
at that point, the unbound subquery can only join things from
`item_type_1`. i can't figure out how to join other relationships of
`list_item`
is it possible to joinedload mutliple trees/paths onto a subqueryload ?
--
You received this message because you are subscribed to the Google Groups
sqlalchemy group.
To unsubscribe from this group and stop receiving emails from it, send an email
to sqlalchemy+unsubscr...@googlegroups.com.
To post to this group, send email to sqlalchemy@googlegroups.com.
Visit this group at http://groups.google.com/group/sqlalchemy.
For more options, visit https://groups.google.com/d/optout.
Re: [sqlalchemy] joinedloads under a subqueryload
On Oct 21, 2014, at 6:07 PM, Jonathan Vanasco jvana...@gmail.com wrote:
I've been staring at this for a while, and can't figure out a way to make the
mapper happy:
i have 3 Classes (tables):
* List (list)
* ListItem (list_item)
* ItemType1 (item_type_1)
* ItemType2 (item_type_2)
* ItemType3 (item_type_3)
until now i've been using a joinedload
query = s.query(List)\
.options(
joinedload('list_item'),
joinedload('list_item.item_type_1'),
joinedload('list_item.item_type_2'),
joinedload('list_item.item_type_3'),
)
The performance is starting to become less than optimal, so I wanted to try
creating a subquery for 'list_items', which has the `item_type_1`/2/3
connected to it as a joinedload
the closest I can get is this:
query = s.query(List)\
.options(
subqueryload('list_item')\
.joinedload('item_type_1')
)
at that point, the unbound subquery can only join things from `item_type_1`.
i can't figure out how to join other relationships of `list_item`
is it possible to joinedload mutliple trees/paths onto a subqueryload ?
in the old way, you’d say:
subqueryload(‘list_item’),
joinedload('list_item.item_type_1'),
joinedload('list_item.item_type_2'),
joinedload('list_item.item_type_3'),
that will still work.
new way you can also say:
subqueryload('list_item').joinedload('item_type_1'),
defaultload('list_item').joinedload(item_type_2'),
defaultload('list_item').joinedload('item_type_3'),
or variants thereof.
--
You received this message because you are subscribed to the Google Groups
sqlalchemy group.
To unsubscribe from this group and stop receiving emails from it, send an
email to sqlalchemy+unsubscr...@googlegroups.com
mailto:sqlalchemy+unsubscr...@googlegroups.com.
To post to this group, send email to sqlalchemy@googlegroups.com
mailto:sqlalchemy@googlegroups.com.
Visit this group at http://groups.google.com/group/sqlalchemy
http://groups.google.com/group/sqlalchemy.
For more options, visit https://groups.google.com/d/optout
https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google Groups
sqlalchemy group.
To unsubscribe from this group and stop receiving emails from it, send an email
to sqlalchemy+unsubscr...@googlegroups.com.
To post to this group, send email to sqlalchemy@googlegroups.com.
Visit this group at http://groups.google.com/group/sqlalchemy.
For more options, visit https://groups.google.com/d/optout.
Re: [sqlalchemy] joinedloads under a subqueryload
subqueryload(‘list_item’),
joinedload('list_item.item_type_1'),
joinedload('list_item.item_type_2'),
joinedload('list_item.item_type_3'),
ah! so sqlalchemy is smart enough to magically map the joinedloads onto
the subqueryload!
I never would have guessed that!
--
You received this message because you are subscribed to the Google Groups
sqlalchemy group.
To unsubscribe from this group and stop receiving emails from it, send an email
to sqlalchemy+unsubscr...@googlegroups.com.
To post to this group, send email to sqlalchemy@googlegroups.com.
Visit this group at http://groups.google.com/group/sqlalchemy.
For more options, visit https://groups.google.com/d/optout.
[sqlalchemy] Active Record/Rails Polymorphic in SqlAlchemy is a Generic Association
Hi, I had been struggling to find how to implement a generic association and the documentation for inherited polymorphic relationships wasn't really helping. After some (a lot) of searching I found some great examples of how to implement what I was looking for. An example of the Rails polymorphic pattern is called a generic foreign key and and can be found here: http://docs.sqlalchemy.org/en/latest/_modules/examples/generic_associations/generic_fk.html Recommended alternatives to the generic foreign key can also be found at: http://docs.sqlalchemy.org/en/latest/orm/examples.html# I just thought I would post this in the hope of saving other people some searching. It might be nice to have a link to the generic association examples in the inheritance documentation (http://docs.sqlalchemy.org/en/rel_0_9/orm/inheritance.html#), but perhaps I was just unlucky. Thank you for the SqlAlchemy! ~Victor -- You received this message because you are subscribed to the Google Groups sqlalchemy group. To unsubscribe from this group and stop receiving emails from it, send an email to sqlalchemy+unsubscr...@googlegroups.com. To post to this group, send email to sqlalchemy@googlegroups.com. Visit this group at http://groups.google.com/group/sqlalchemy. For more options, visit https://groups.google.com/d/optout.
