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:
On 10/17/2014 02:52 PM, JPLaverdure wrote:
Hello,
It seems a number of SAWarnings are being thrown whenever I
instantiate Versioned objects which make use of inheritance:
|
SAWarning:Implicitlycombining column container_history.changed
withcolumn barcoded_container_history.changed under
On Oct 17, 2014, at 3:50 PM, JPLaverdure jp.laverd...@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
