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