[sqlalchemy] Active Record/Rails Polymorphic in SqlAlchemy is a Generic Association

[Victor Reichert]

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.

Re: [sqlalchemy] joinedloads under a subqueryload

[Jonathan Vanasco]

>
> 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.

Re: [sqlalchemy] joinedloads under a subqueryload

[Michael Bayer]

> On Oct 21, 2014, at 6:07 PM, Jonathan Vanasco  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 
> .
> 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 
> .

-- 
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

[Jonathan Vanasco]

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] SAWarnings when using history_meta.py versioning and Inheritance.

[JPLaverdure]

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  > 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  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 .
> 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+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.

[Michael Bayer]

“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  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 > 
>> 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+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 
> .

-- 
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.

[JPLaverdure]

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  > 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+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.