On Sat, Feb 15, 2020, at 3:27 PM, Mark Aquino wrote:
> “You can use a @property so that when you get back an A or a B object , they
> seek to return either the column on A or the column on B.“
>
> I believe you’re describing the behavior I currently have, I.e. if I query B
> then I can get
“You can use a @property so that when you get back an A or a B object , they
seek to return either the column on A or the column on B.“
I believe you’re describing the behavior I currently have, I.e. if I query B
then I can get b.visible_id otherwise I get A.visible_id.
I see your point about
On Fri, Feb 14, 2020, at 12:35 PM, Mark Aquino wrote:
> I have a polymorphic class structure like this, with a lot of classes
> extending the parent class.
> In reality I'm using a Mixin that declares the visible_id column and it's
> defined with @declared_attr.cascading, but for simplicity:
There's no point in really having the visible_id on the A table, other than
for inheritance.
The point of it being on B (and C, D, E, F, etc.) is that they have unique
sequences populating those "Visible IDs", so I have can have a B-1 and a
C-1 and a D-1.
In other words I have my parent table
There's no point in really having the visible_id on the A table, other than
for inheritance.
The point of it being on B (and C, D, E, F, etc.) is that they have unique
sequences populating those "Visible IDs", so I have can have a B-1 and a
C-1 and a D-1.
In other words I have my parent table
On Fri, Feb 14, 2020 at 5:35 PM Mark Aquino wrote:
>
> I have a polymorphic class structure like this, with a lot of classes
> extending the parent class.
> In reality I'm using a Mixin that declares the visible_id column and it's
> defined with @declared_attr.cascading, but for simplicity:
>
>
I have a polymorphic class structure like this, with a lot of classes
extending the parent class.
In reality I'm using a Mixin that declares the visible_id column and it's
defined with @declared_attr.cascading, but for simplicity:
class A(Base):
__tablename__ = 'a'
id =
