bojanb wrote:
>
> This does it. One small drawback is that since the field is now
> defined as an attribute, one can't query on it (ie. session.query
> (class_).filter_by(modified_by='jack')), but we don't envison such a
> use case for this funcionality so it's OK for us.
you get this by using "s
This does it. One small drawback is that since the field is now
defined as an attribute, one can't query on it (ie. session.query
(class_).filter_by(modified_by='jack')), but we don't envison such a
use case for this funcionality so it's OK for us.
Recap of what was done: table columns were defin
xaotuk wrote:
>
> We have tried suggested, but: field 'modified' exists in both parent
> and child tables, when we redefined property 'modified' in mapper with
> something like this:
> mapper(Child, child_table, properties={'modified' =
> child_table.c.modified, ...}), modified field still returne
We have tried suggested, but: field 'modified' exists in both parent
and child tables, when we redefined property 'modified' in mapper with
something like this:
mapper(Child, child_table, properties={'modified' =
child_table.c.modified, ...}), modified field still returned value
from parent's tabl
bojanb wrote:
>
> Hi,
>
> Can I have identical column names in both parent and child classes
> that are part of a joined-table inheritance? These are simply created,
> created_by, modified, modified_by columns that are populated by
> defaults defined for them (ie. default, server_default, onupdate
