[sqlalchemy] Re: multiple inheritance experiment
Thank you, In the last suggestion: @property def users_and_orders(self): return self.users + self.orders or to simulate a polymorphic union, do object_session(self).query().union(object_session(self).query()) etc. Do you have any suggestions to make the result have an append/remove method which persists to the database? Perhaps with a descriptor or custom collection type? Cheers, Lars On Apr 15, 6:49 am, Michael Bayer wrote: > On Apr 13, 2011, at 5:52 AM, Lars wrote: > > > Hi Michael, > > > I am trying to figure out the two suggestions you did, and not getting > > very far. Some basic questions: > > > - if A, B, C are mapped classes, can you do A.join(B, A.id == > > B.id).join(C, B.id == C.id).join( ? > > usually if you want to use join() you'd deal with tables, like > table_a.join(table_b, ...).join(...). though the orm.join() function will > receive classes directly, its > inhttp://www.sqlalchemy.org/docs/orm/tutorial.html#querying-with-joins > > > - Would using join in such a way make access to mapped attributes in > > one of the joined tables excessively slow? > > joins are slower than straight single table selects especially in MySQL, if > thats the question > > > - What is the difference between using association_proxy and > > relationship(... secondary = .., ..., secondaryjoin = ...)? > > three concepts. one is > many-to-many:http://www.sqlalchemy.org/docs/orm/relationships.html#many-to-many next > is the association pattern, a many to many where extra data is linked with > each > association:http://www.sqlalchemy.org/docs/orm/relationships.html#association-object next > is association proxy, when you've worked with an association for awhile and > are tired of saying parent.association.child and want to just skip the > ".association" part in the usual case > > > - in the example in poly_assoc_generic.py, is there a way to define an > > attribute on address that returns a list with both "orders" and > > "users" with that address (and be able to append that list) ? > > these collections load from entirely different tables. Usually you'd need to > do it manually: > > @property > def users_and_orders(self): > return self.users + self.orders > > or to simulate a polymorphic union, do > object_session(self).query().union(object_session(self).query()) etc. -- You received this message because you are subscribed to the Google Groups "sqlalchemy" group. To post to this group, send email to sqlalchemy@googlegroups.com. To unsubscribe from this group, send email to sqlalchemy+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sqlalchemy?hl=en.
Re: [sqlalchemy] Re: multiple inheritance experiment
On Apr 13, 2011, at 5:52 AM, Lars wrote: > Hi Michael, > > I am trying to figure out the two suggestions you did, and not getting > very far. Some basic questions: > > - if A, B, C are mapped classes, can you do A.join(B, A.id == > B.id).join(C, B.id == C.id).join( ? usually if you want to use join() you'd deal with tables, like table_a.join(table_b, ...).join(...). though the orm.join() function will receive classes directly, its in http://www.sqlalchemy.org/docs/orm/tutorial.html#querying-with-joins > - Would using join in such a way make access to mapped attributes in > one of the joined tables excessively slow? joins are slower than straight single table selects especially in MySQL, if thats the question > - What is the difference between using association_proxy and > relationship(... secondary = .., ..., secondaryjoin = ...)? three concepts. one is many-to-many: http://www.sqlalchemy.org/docs/orm/relationships.html#many-to-many next is the association pattern, a many to many where extra data is linked with each association: http://www.sqlalchemy.org/docs/orm/relationships.html#association-object next is association proxy, when you've worked with an association for awhile and are tired of saying parent.association.child and want to just skip the ".association" part in the usual case > - in the example in poly_assoc_generic.py, is there a way to define an > attribute on address that returns a list with both "orders" and > "users" with that address (and be able to append that list) ? these collections load from entirely different tables. Usually you'd need to do it manually: @property def users_and_orders(self): return self.users + self.orders or to simulate a polymorphic union, do object_session(self).query().union(object_session(self).query()) etc. -- You received this message because you are subscribed to the Google Groups "sqlalchemy" group. To post to this group, send email to sqlalchemy@googlegroups.com. To unsubscribe from this group, send email to sqlalchemy+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sqlalchemy?hl=en.
[sqlalchemy] Re: multiple inheritance experiment
Hi Michael,
I am trying to figure out the two suggestions you did, and not getting
very far. Some basic questions:
- if A, B, C are mapped classes, can you do A.join(B, A.id ==
B.id).join(C, B.id == C.id).join( ?
- Would using join in such a way make access to mapped attributes in
one of the joined tables excessively slow?
- What is the difference between using association_proxy and
relationship(... secondary = .., ..., secondaryjoin = ...)?
- in the example in poly_assoc_generic.py, is there a way to define an
attribute on address that returns a list with both "orders" and
"users" with that address (and be able to append that list) ?
Please help, Lars
On Apr 11, 8:45 pm, Lars wrote:
> Hi again,
>
> On Apr 10, 11:17 pm, Michael Bayer wrote:> On Apr
> 10, 2011, at 1:27 PM, Lars wrote:
>
> > > Hi Michael,
>
> > > Thank you for the suggestions.
>
> > > I noticed that all the foreign keys to superclasses are identical
> > > (same id number). What would be the disadvantage of using only primary
> > > keys and using those in setting up relationships (compared to using
> > > foreign keys)?
>
> > When two columns in a relational database, one being a primary key, the
> > other being possibly a primary key, are logically constrained to have the
> > same value, that's known as a foreign key. It's then best practice to
> > actually place a real foreign key constraint in the database to enforce
> > this at the data level. SQLite and MySQL by default don't enforce it,
> > though. SQLAlchemy doesn't particularly care if an actual constraint is
> > defined in the database, it can be told to join on any combination of
> > columns. The presence of a foreign key within table metadata just makes
> > this automatic.
>
> Does that mean that if you don't set the foreign key constraint and
> you want to be able to set an attribute, you also have to write code
> to copy the primary key of the parent to the child?
>
> > > If I use a root base class (similar to "object" in python) and add a
> > > type column/attribute to refer to the actual class of the object/
> > > record, is there an elegant way to get/set/del the polymorphic
> > > attribute object of the correct class using this type?
>
> > Which table is this "type" column present in, base1 or base2 ?
>
> Neither, I was thinking of using a class that is the root base class
> of all classes (not present in code above) to store the type and the
> "primary key" of all objects. This "type" should be accessible in all
> classes, since they would all be direct or indirect subclasses of this
> root class. Say that I store all classes in a dictionary called
> registry, then registry[type] would give the actual class of the
> object identified with the primary key in the root class table. This
> key would also identify the correct record in all superclasses of this
> class, e.g. to be used in a join over these classes.
>
> (hope this is somewhat clear ...)
>
>
>
> > > Would it be possible to redefine query() using this type to first
> > > resolve the correct table and use the query method SA provides on that
> > > (without this resulting in otherwise changing the API) ?
>
> > but what's the "correct" table, base1, base2, claz ? with multiple
> > inheritance the path is not a straight line. If you have a mostly straight
> > inheritance model with an occasional offshoot, say its base1 -> subbase1 ->
> > (subbase1 , base2) -> claz, I'd use traditional inheritance and have just
> > "base2" via relationship().
>
> The correct table would be the table corresponding to the value in the
> type column. I am working on a framework where others will design the
> data structure and would like to use a uniform metadata model to avoid
> extra choices for the designer.
>
>
>
> Cheers again, Lars
>
>
>
>
>
>
>
>
>
> > > On Apr 7, 8:42 pm, Michael Bayer wrote:
> > >> On Apr 7, 2011, at 2:30 PM, Lars wrote:
>
> > >>> Hello,
>
> > >>> I am pretty determined to find a way to get (a simplified version of)
> > >>> multiple inheritance working with SA. The simplification lies in that
> > >>> no overriding of attributes will be possible (but I don't know whether
> > >>> that is significant). I was thinking of a schema as follows:
>
> > >>> ---
> > >>> ---
>
> > >>> metadata = MetaData()
>
> > >>> base1_table = Table("base1_table", metadata,
> > >>> Column('id', Integer, primary_key=True),
> > >>> Column('str', String)
> > >>> )
>
> > >>> base2_table = Table("base2_table", metadata,
> > >>> Column('id', Integer, primary_key=True),
> > >>> Column('int', Integer)
> > >>> )
>
> > >>> claz1_table = Table("claz1_table", metadata,
> > >>> Column('id', Integer, primary_key=True),
> > >>> Column('base1_id', None, ForeignKey('base1_table.id')),
> > >>> Column('base2_id', None, ForeignKey('base2_table.id')),
> > >>> Column('assoc_id', None, ForeignKey('assoc_table.id')
[sqlalchemy] Re: multiple inheritance experiment
Hi again,
On Apr 10, 11:17 pm, Michael Bayer wrote:
> On Apr 10, 2011, at 1:27 PM, Lars wrote:
>
> > Hi Michael,
>
> > Thank you for the suggestions.
>
> > I noticed that all the foreign keys to superclasses are identical
> > (same id number). What would be the disadvantage of using only primary
> > keys and using those in setting up relationships (compared to using
> > foreign keys)?
>
> When two columns in a relational database, one being a primary key, the other
> being possibly a primary key, are logically constrained to have the same
> value, that's known as a foreign key. It's then best practice to actually
> place a real foreign key constraint in the database to enforce this at the
> data level. SQLite and MySQL by default don't enforce it, though.
> SQLAlchemy doesn't particularly care if an actual constraint is defined in
> the database, it can be told to join on any combination of columns. The
> presence of a foreign key within table metadata just makes this automatic.
>
Does that mean that if you don't set the foreign key constraint and
you want to be able to set an attribute, you also have to write code
to copy the primary key of the parent to the child?
>
> > If I use a root base class (similar to "object" in python) and add a
> > type column/attribute to refer to the actual class of the object/
> > record, is there an elegant way to get/set/del the polymorphic
> > attribute object of the correct class using this type?
>
> Which table is this "type" column present in, base1 or base2 ?
>
Neither, I was thinking of using a class that is the root base class
of all classes (not present in code above) to store the type and the
"primary key" of all objects. This "type" should be accessible in all
classes, since they would all be direct or indirect subclasses of this
root class. Say that I store all classes in a dictionary called
registry, then registry[type] would give the actual class of the
object identified with the primary key in the root class table. This
key would also identify the correct record in all superclasses of this
class, e.g. to be used in a join over these classes.
(hope this is somewhat clear ...)
>
> > Would it be possible to redefine query() using this type to first
> > resolve the correct table and use the query method SA provides on that
> > (without this resulting in otherwise changing the API) ?
>
> but what's the "correct" table, base1, base2, claz ? with multiple
> inheritance the path is not a straight line. If you have a mostly straight
> inheritance model with an occasional offshoot, say its base1 -> subbase1 ->
> (subbase1 , base2) -> claz, I'd use traditional inheritance and have just
> "base2" via relationship().
>
The correct table would be the table corresponding to the value in the
type column. I am working on a framework where others will design the
data structure and would like to use a uniform metadata model to avoid
extra choices for the designer.
>
Cheers again, Lars
>
> > On Apr 7, 8:42 pm, Michael Bayer wrote:
> >> On Apr 7, 2011, at 2:30 PM, Lars wrote:
>
> >>> Hello,
>
> >>> I am pretty determined to find a way to get (a simplified version of)
> >>> multiple inheritance working with SA. The simplification lies in that
> >>> no overriding of attributes will be possible (but I don't know whether
> >>> that is significant). I was thinking of a schema as follows:
>
> >>> ---
> >>> ---
>
> >>> metadata = MetaData()
>
> >>> base1_table = Table("base1_table", metadata,
> >>> Column('id', Integer, primary_key=True),
> >>> Column('str', String)
> >>> )
>
> >>> base2_table = Table("base2_table", metadata,
> >>> Column('id', Integer, primary_key=True),
> >>> Column('int', Integer)
> >>> )
>
> >>> claz1_table = Table("claz1_table", metadata,
> >>> Column('id', Integer, primary_key=True),
> >>> Column('base1_id', None, ForeignKey('base1_table.id')),
> >>> Column('base2_id', None, ForeignKey('base2_table.id')),
> >>> Column('assoc_id', None, ForeignKey('assoc_table.id'))
> >>> )
>
> >>> assoc_table = Table("assoc_table", metadata,
> >>> Column('id', Integer, primary_key=True),
> >>> Column('name', String(50), nullable=False),
> >>> Column('type', String(50), nullable=False)
> >>> )
>
> >>> base3_table = Table("base3_table", metadata,
> >>> Column('id', Integer, primary_key=True),
> >>> Column('assoc_id', None, ForeignKey('assoc_table.id')),
> >>> Column('bool', Boolean)
> >>> )
>
> >>> claz2_table = Table("claz2_table", metadata,
> >>> Column('id', Integer, primary_key=True),
> >>> Column('base3_id', None, ForeignKey('base3_table.id')),
> >>> Column('date', Date)
> >>> )
>
> >>> class base1(object):
> >>> pass
> >>> class base2(object):
> >>> pass
> >>> class base3(object):
> >>> pass
> >>> class claz1(base1, base2):
> >>> pass
> >>> class claz2(base3):
> >>> pass
>
> >>> # d
Re: [sqlalchemy] Re: multiple inheritance experiment
On Apr 10, 2011, at 1:27 PM, Lars wrote:
> Hi Michael,
>
> Thank you for the suggestions.
>
> I noticed that all the foreign keys to superclasses are identical
> (same id number). What would be the disadvantage of using only primary
> keys and using those in setting up relationships (compared to using
> foreign keys)?
When two columns in a relational database, one being a primary key, the other
being possibly a primary key, are logically constrained to have the same value,
that's known as a foreign key. It's then best practice to actually place a
real foreign key constraint in the database to enforce this at the data level.
SQLite and MySQL by default don't enforce it, though. SQLAlchemy doesn't
particularly care if an actual constraint is defined in the database, it can be
told to join on any combination of columns. The presence of a foreign key
within table metadata just makes this automatic.
>
> If I use a root base class (similar to object in python) and add a
> type column/attribute to refer to the actual class of the object/
> record, is there an elegant way to get/set/del the polymorphic
> attribute object of the correct class using this type?
Which table is this "type" column present in, base1 or base2 ?
>
> Would it be possible to redefine query() using this type to first
> resolve the correct table and use the query method SA provides on that
> (without this resulting in otherwise changing the API) ?
but what's the "correct" table, base1, base2, claz ?with multiple
inheritance the path is not a straight line. If you have a mostly straight
inheritance model with an occasional offshoot, say its base1 -> subbase1 ->
(subbase1 , base2) -> claz, I'd use traditional inheritance and have just
"base2" via relationship().
>
> Cheers, Lars
>
>
> On Apr 7, 8:42 pm, Michael Bayer wrote:
>> On Apr 7, 2011, at 2:30 PM, Lars wrote:
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>> Hello,
>>
>>> I am pretty determined to find a way to get (a simplified version of)
>>> multiple inheritance working with SA. The simplification lies in that
>>> no overriding of attributes will be possible (but I don't know whether
>>> that is significant). I was thinking of a schema as follows:
>>
>>> ---
>>> ---
>>
>>> metadata = MetaData()
>>
>>> base1_table = Table("base1_table", metadata,
>>>Column('id', Integer, primary_key=True),
>>>Column('str', String)
>>>)
>>
>>> base2_table = Table("base2_table", metadata,
>>>Column('id', Integer, primary_key=True),
>>>Column('int', Integer)
>>>)
>>
>>> claz1_table = Table("claz1_table", metadata,
>>>Column('id', Integer, primary_key=True),
>>>Column('base1_id', None, ForeignKey('base1_table.id')),
>>>Column('base2_id', None, ForeignKey('base2_table.id')),
>>>Column('assoc_id', None, ForeignKey('assoc_table.id'))
>>>)
>>
>>> assoc_table = Table("assoc_table", metadata,
>>>Column('id', Integer, primary_key=True),
>>>Column('name', String(50), nullable=False),
>>>Column('type', String(50), nullable=False)
>>> )
>>
>>> base3_table = Table("base3_table", metadata,
>>>Column('id', Integer, primary_key=True),
>>>Column('assoc_id', None, ForeignKey('assoc_table.id')),
>>>Column('bool', Boolean)
>>>)
>>
>>> claz2_table = Table("claz2_table", metadata,
>>>Column('id', Integer, primary_key=True),
>>>Column('base3_id', None, ForeignKey('base3_table.id')),
>>>Column('date', Date)
>>>)
>>
>>> class base1(object):
>>>pass
>>> class base2(object):
>>>pass
>>> class base3(object):
>>>pass
>>> class claz1(base1, base2):
>>>pass
>>> class claz2(base3):
>>>pass
>>
>>> # do mappings, relationships and e.g. be able to
>>
>>> c1 = claz1(str = "hello", int = 17)
>>> setattr(c1, name, claz2(bool = True, date = Date(2010,9,10)))
>>
>> You can just forego the "inherits" flag and map each class to the
>> appropriate join or base table. claz1 would be mapped to a join of the
>> three tables involved.The difficult part of course is the query side, if
>> you're looking to query "base1" or "base2" and get back "claz1" objects.
>>
>> Alternatively, each class can be mapped to one table only, and
>> relationship() used to link to other tables. Again if you don't use the
>> "inherits" flag, you can maintain the class hierarchy on the Python side and
>> use association proxies to provide local access to attributes that are
>> normally on the related class. This would still not give you polymorphic
>> loading but would grant a little more flexibility in which tables are
>> queried to start.
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>> ---
>>> --
>>
>>> I am still pretty new to SA. Can anyone give me any hints, tips,
>>> issues with this scheme (e.g. about how to
[sqlalchemy] Re: multiple inheritance experiment
Hi Michael,
Thank you for the suggestions.
I noticed that all the foreign keys to superclasses are identical
(same id number). What would be the disadvantage of using only primary
keys and using those in setting up relationships (compared to using
foreign keys)?
If I use a root base class (similar to object in python) and add a
type column/attribute to refer to the actual class of the object/
record, is there an elegant way to get/set/del the polymorphic
attribute object of the correct class using this type? Would that be
possible with the first option you described above?
Would it be possible to redefine query() using this type to first
resolve the correct table and use the query method SA provides on that
(without this resulting in otherwise changing the API) ?
Cheers, Lars
On Apr 7, 8:42 pm, Michael Bayer wrote:
> On Apr 7, 2011, at 2:30 PM, Lars wrote:
>
>
>
>
>
>
>
>
>
> > Hello,
>
> > I am pretty determined to find a way to get (a simplified version of)
> > multiple inheritance working with SA. The simplification lies in that
> > no overriding of attributes will be possible (but I don't know whether
> > that is significant). I was thinking of a schema as follows:
>
> > ---
> > ---
>
> > metadata = MetaData()
>
> > base1_table = Table("base1_table", metadata,
> > Column('id', Integer, primary_key=True),
> > Column('str', String)
> > )
>
> > base2_table = Table("base2_table", metadata,
> > Column('id', Integer, primary_key=True),
> > Column('int', Integer)
> > )
>
> > claz1_table = Table("claz1_table", metadata,
> > Column('id', Integer, primary_key=True),
> > Column('base1_id', None, ForeignKey('base1_table.id')),
> > Column('base2_id', None, ForeignKey('base2_table.id')),
> > Column('assoc_id', None, ForeignKey('assoc_table.id'))
> > )
>
> > assoc_table = Table("assoc_table", metadata,
> > Column('id', Integer, primary_key=True),
> > Column('name', String(50), nullable=False),
> > Column('type', String(50), nullable=False)
> > )
>
> > base3_table = Table("base3_table", metadata,
> > Column('id', Integer, primary_key=True),
> > Column('assoc_id', None, ForeignKey('assoc_table.id')),
> > Column('bool', Boolean)
> > )
>
> > claz2_table = Table("claz2_table", metadata,
> > Column('id', Integer, primary_key=True),
> > Column('base3_id', None, ForeignKey('base3_table.id')),
> > Column('date', Date)
> > )
>
> > class base1(object):
> > pass
> > class base2(object):
> > pass
> > class base3(object):
> > pass
> > class claz1(base1, base2):
> > pass
> > class claz2(base3):
> > pass
>
> > # do mappings, relationships and e.g. be able to
>
> > c1 = claz1(str = "hello", int = 17)
> > setattr(c1, name, claz2(bool = True, date = Date(2010,9,10)))
>
> You can just forego the "inherits" flag and map each class to the appropriate
> join or base table. claz1 would be mapped to a join of the three tables
> involved. The difficult part of course is the query side, if you're
> looking to query "base1" or "base2" and get back "claz1" objects.
>
> Alternatively, each class can be mapped to one table only, and relationship()
> used to link to other tables. Again if you don't use the "inherits" flag,
> you can maintain the class hierarchy on the Python side and use association
> proxies to provide local access to attributes that are normally on the
> related class. This would still not give you polymorphic loading but would
> grant a little more flexibility in which tables are queried to start.
>
>
>
>
>
>
>
>
>
> > ---
> > --
>
> > I am still pretty new to SA. Can anyone give me any hints, tips,
> > issues with this scheme (e.g. about how to do the mappings,
> > descriptors, etc)?
>
> > The step after will be to write factory functions/metaclasses to
> > generate these dynamically.
>
> > Multiple inheritance is very important for my use case.
>
> > Cheers, Lars
>
> > --
> > You received this message because you are subscribed to the Google Groups
> > "sqlalchemy" group.
> > To post to this group, send email to sqlalchemy@googlegroups.com.
> > To unsubscribe from this group, send email to
> > sqlalchemy+unsubscr...@googlegroups.com.
> > For more options, visit this group
> > athttp://groups.google.com/group/sqlalchemy?hl=en.
--
You received this message because you are subscribed to the Google Groups
"sqlalchemy" group.
To post to this group, send email to sqlalchemy@googlegroups.com.
To unsubscribe from this group, send email to
sqlalchemy+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/sqlalchemy?hl=en.
[sqlalchemy] Re: Multiple Inheritance
On Sep 5, 2:27 pm, Michael Bayer <[EMAIL PROTECTED]> wrote: > this looks pretty impressive ! I was poking around today to see how > hard it would be to make "inherits" a list. It seems like some > things would be straightforward, others not. Its interesting and I'm > still thinking about it. But its good you could make it work without > getting into all of that. Thanks Michael, and thanks for your help. It was your suggestion to do chained joins that was the key. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "sqlalchemy" group. To post to this group, send email to sqlalchemy@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sqlalchemy?hl=en -~--~~~~--~~--~--~---
[sqlalchemy] Re: Multiple Inheritance
On Sep 5, 2:14 pm, [EMAIL PROTECTED] wrote: > just a theoretical comment... so instead of relying on SA mapper logic > to automaticaly put the discriminator/s, u are doing it on a level > above, in a way - as SA does not know about the (multiple) > inheritance that those imply. can be useful as an approach for > other 'beyond SA' things... That's right, SQLA is not handling the inheritance directly. In some sense this is nice because there is nothing going on 'under the hood' (at least nothing related to the inheritance structure). > will it work for multilevel inheritance? I don't think so. This issue did come up but we don't use it in our application so that's ok. I'm not sure how the table joins would work and how the discriminator setting would work. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "sqlalchemy" group. To post to this group, send email to sqlalchemy@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sqlalchemy?hl=en -~--~~~~--~~--~--~---
[sqlalchemy] Re: Multiple Inheritance
this looks pretty impressive ! I was poking around today to see how
hard it would be to make "inherits" a list. It seems like some
things would be straightforward, others not. Its interesting and I'm
still thinking about it. But its good you could make it work without
getting into all of that.
On Sep 5, 2008, at 2:56 PM, Sam Magister wrote:
>
> I've come up with an implementation based on concrete table
> inheritance, without touching any SQLA internals like Michael
> suggested. I've also added a discriminator to both base classes,
> 'citizen_type' and 'employee_type'. The discriminator is set via the
> before_insert() method of a MapperExtension which extends the Engineer
> mapper.
>
> I realize that going this way forfeits the advantages of the
> polymorphic querying, but that's ok for my application. I can still
> get the same resuts, it just takes a few subqueries after I query one
> of the base classes.
>
> I've run a few tests with this setup and it seems to work - the crux
> is in the engineers.join(employees).join(citizens) table definition in
> the Engineer mapper and the ForeignKey constraints.
>
> I just wanted to put this out there to see if anyone notices any
> issues I am not anticipating or if this model might be helpful to
> someone in the future who wants to inherit from two independent base
> classes. I realize that the Engineers inheriting from Employees and
> Citizens example is a bit forced, sorry about that. This is not my
> actual application, I just wanted to give a simple example. Perhaps a
> better application would be having 'Dragon' inheriting from both
> 'Bird' and 'Lizard', as given in the Agile Data essay linked to
> earlier.
>
> Here's the setup:
>
> employees = Table('employees', metadata,
> Column('employee_id', Integer, primary_key=True),
> Column('employee_type', String(30), nullable=False)
> )
>
> citizens = Table('citizens', metadata,
> Column('citizen_id', Integer, primary_key=True),
> Column('citizen_type', String(30), nullable=False)
> )
>
> An engineer who is both an employee and a citizen would have an
> employee_id and a citizen_id:
>
> engineers = Table('engineers', metadata,
> Column('id', Integer, primary_key=True)
> Column('employee_id', Integer,
> ForeignKey('employees.employee_id')),
> Column('citizen_id', Integer, ForeignKey('citizens.citizen_id')),
> Column('engineer_info', String(50)),
> )
>
> And the classes look like:
>
> class Employee(object):
>pass
>
> class Citizen(object):
>pass
>
> class Engineer(Employe, Citizen):
>pass
>
> This is the mapper extension for setting the discriminators:
>
> class EngineerExtension(MapperExtension):
>
> def __init__(self):
>MapperExtension.__init__(self)
>
> def before_insert(self, mapper, connection, instance):
>instance.employee_type = 'engineer'
>instance.citizen_type = 'engineer'
>
> And the mappers:
>
> mapper(Engineer, engineers.join(employees).join(citizens),
> extension=EngineerExtension())
> mapper(Employee, employees)
> mapper(Citizen, citizens)
>
> Any comments on this setup are welcome!
>
> Sam
> >
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"sqlalchemy" group.
To post to this group, send email to sqlalchemy@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/sqlalchemy?hl=en
-~--~~~~--~~--~--~---
[sqlalchemy] Re: Multiple Inheritance
just a theoretical comment... so instead of relying on SA mapper logic
to automaticaly put the discriminator/s, u are doing it on a level
above, in a way - as SA does not know about the (multiple)
inheritance that those imply. can be useful as an approach for
other 'beyond SA' things...
will it work for multilevel inheritance?
btw i would not call it concrete-table inh, as Engineer has only
foreignkeys to other tables (like joined-table) and not their data
columns. but it isnt joined-table either. inbetween...
On Friday 05 September 2008 21:56:28 Sam Magister wrote:
> I've come up with an implementation based on concrete table
> inheritance, without touching any SQLA internals like Michael
> suggested. I've also added a discriminator to both base classes,
> 'citizen_type' and 'employee_type'. The discriminator is set via
> the before_insert() method of a MapperExtension which extends the
> Engineer mapper.
>
> I realize that going this way forfeits the advantages of the
> polymorphic querying, but that's ok for my application. I can still
> get the same resuts, it just takes a few subqueries after I query
> one of the base classes.
>
> I've run a few tests with this setup and it seems to work - the
> crux is in the engineers.join(employees).join(citizens) table
> definition in the Engineer mapper and the ForeignKey constraints.
>
> I just wanted to put this out there to see if anyone notices any
> issues I am not anticipating or if this model might be helpful to
> someone in the future who wants to inherit from two independent
> base classes. I realize that the Engineers inheriting from
> Employees and Citizens example is a bit forced, sorry about that.
> This is not my actual application, I just wanted to give a simple
> example. Perhaps a better application would be having 'Dragon'
> inheriting from both 'Bird' and 'Lizard', as given in the Agile
> Data essay linked to earlier.
>
> Here's the setup:
>
> employees = Table('employees', metadata,
> Column('employee_id', Integer, primary_key=True),
> Column('employee_type', String(30), nullable=False)
> )
>
> citizens = Table('citizens', metadata,
> Column('citizen_id', Integer, primary_key=True),
> Column('citizen_type', String(30), nullable=False)
> )
>
> An engineer who is both an employee and a citizen would have an
> employee_id and a citizen_id:
>
> engineers = Table('engineers', metadata,
> Column('id', Integer, primary_key=True)
> Column('employee_id', Integer,
> ForeignKey('employees.employee_id')),
> Column('citizen_id', Integer, ForeignKey('citizens.citizen_id')),
> Column('engineer_info', String(50)),
> )
>
> And the classes look like:
>
> class Employee(object):
> pass
>
> class Citizen(object):
> pass
>
> class Engineer(Employe, Citizen):
> pass
>
> This is the mapper extension for setting the discriminators:
>
> class EngineerExtension(MapperExtension):
>
> def __init__(self):
> MapperExtension.__init__(self)
>
> def before_insert(self, mapper, connection, instance):
> instance.employee_type = 'engineer'
> instance.citizen_type = 'engineer'
>
> And the mappers:
>
> mapper(Engineer, engineers.join(employees).join(citizens),
> extension=EngineerExtension())
> mapper(Employee, employees)
> mapper(Citizen, citizens)
>
> Any comments on this setup are welcome!
>
> Sam
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"sqlalchemy" group.
To post to this group, send email to sqlalchemy@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/sqlalchemy?hl=en
-~--~~~~--~~--~--~---
[sqlalchemy] Re: Multiple Inheritance
I've come up with an implementation based on concrete table
inheritance, without touching any SQLA internals like Michael
suggested. I've also added a discriminator to both base classes,
'citizen_type' and 'employee_type'. The discriminator is set via the
before_insert() method of a MapperExtension which extends the Engineer
mapper.
I realize that going this way forfeits the advantages of the
polymorphic querying, but that's ok for my application. I can still
get the same resuts, it just takes a few subqueries after I query one
of the base classes.
I've run a few tests with this setup and it seems to work - the crux
is in the engineers.join(employees).join(citizens) table definition in
the Engineer mapper and the ForeignKey constraints.
I just wanted to put this out there to see if anyone notices any
issues I am not anticipating or if this model might be helpful to
someone in the future who wants to inherit from two independent base
classes. I realize that the Engineers inheriting from Employees and
Citizens example is a bit forced, sorry about that. This is not my
actual application, I just wanted to give a simple example. Perhaps a
better application would be having 'Dragon' inheriting from both
'Bird' and 'Lizard', as given in the Agile Data essay linked to
earlier.
Here's the setup:
employees = Table('employees', metadata,
Column('employee_id', Integer, primary_key=True),
Column('employee_type', String(30), nullable=False)
)
citizens = Table('citizens', metadata,
Column('citizen_id', Integer, primary_key=True),
Column('citizen_type', String(30), nullable=False)
)
An engineer who is both an employee and a citizen would have an
employee_id and a citizen_id:
engineers = Table('engineers', metadata,
Column('id', Integer, primary_key=True)
Column('employee_id', Integer,
ForeignKey('employees.employee_id')),
Column('citizen_id', Integer, ForeignKey('citizens.citizen_id')),
Column('engineer_info', String(50)),
)
And the classes look like:
class Employee(object):
pass
class Citizen(object):
pass
class Engineer(Employe, Citizen):
pass
This is the mapper extension for setting the discriminators:
class EngineerExtension(MapperExtension):
def __init__(self):
MapperExtension.__init__(self)
def before_insert(self, mapper, connection, instance):
instance.employee_type = 'engineer'
instance.citizen_type = 'engineer'
And the mappers:
mapper(Engineer, engineers.join(employees).join(citizens),
extension=EngineerExtension())
mapper(Employee, employees)
mapper(Citizen, citizens)
Any comments on this setup are welcome!
Sam
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"sqlalchemy" group.
To post to this group, send email to sqlalchemy@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/sqlalchemy?hl=en
-~--~~~~--~~--~--~---
[sqlalchemy] Re: Multiple Inheritance
On Sep 4, 2008, at 2:12 PM, Sam Magister wrote: > Michael, what would the mapper function look like if it were to map > Engineer(Employee, Citizen) to > engineers.join(citizens).join(employees). What argument of the mapper > would that join condition be in? I think concrete inheritance might be > the way to go about things, at the cost of the nice polymorphic > loading features. that would just be the ordinary "table" argument. The join conditions are within the join() calls themselves. mapper(Engineer, engineers.join(citizens,...).join(employees, ...)) . I dont think you can even say "concrete=True" here unless there were an "inherits" argument, in which case you'd have to just pick a superclass out of the two it would be better to not use the inherits argument at all though (pretty sure SQLA won't complain). --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "sqlalchemy" group. To post to this group, send email to sqlalchemy@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sqlalchemy?hl=en -~--~~~~--~~--~--~---
[sqlalchemy] Re: Multiple Inheritance
sorry for the rant. my second response is closer to the mark. On Sep 4, 2008, at 2:01 PM, Sam Magister wrote: > > Michael, > > Thanks for the thoughtful replies. I'm going to explore the options > you raised here. I'll post back with any insights I come to. > > Best, > > Sam > > --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "sqlalchemy" group. To post to this group, send email to sqlalchemy@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sqlalchemy?hl=en -~--~~~~--~~--~--~---
[sqlalchemy] Re: Multiple Inheritance
On Sep 3, 8:25 pm, Michael Bayer <[EMAIL PROTECTED]> wrote: > You can certainly map to any of the hierarchies indicated in that > article, but you wouldn't be able to take advantage of SQLA's > "polymorphic" capabilities, which are designed to only handle single > inheritance. You'd really want to make your Engineer(Employee, > Citizen) class and just map it to > engineers.join(citizens).join(employees). That would get your schema > going, just without SQLA having any awareness of the "inheritance" > portion of it, and is extremely similar to a plain concrete setup, > which is pretty much all you'd get anyway without the ability to load > polymorphically. > Michael, what would the mapper function look like if it were to map Engineer(Employee, Citizen) to engineers.join(citizens).join(employees). What argument of the mapper would that join condition be in? I think concrete inheritance might be the way to go about things, at the cost of the nice polymorphic loading features. Thanks, Sam --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "sqlalchemy" group. To post to this group, send email to sqlalchemy@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sqlalchemy?hl=en -~--~~~~--~~--~--~---
[sqlalchemy] Re: Multiple Inheritance
Michael, Thanks for the thoughtful replies. I'm going to explore the options you raised here. I'll post back with any insights I come to. Best, Sam --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "sqlalchemy" group. To post to this group, send email to sqlalchemy@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sqlalchemy?hl=en -~--~~~~--~~--~--~---
[sqlalchemy] Re: Multiple Inheritance
On Sep 3, 2008, at 11:25 PM, Michael Bayer wrote: > > This pattern doesnt entirely make sense - the "citizen_type" and > "employee_type" columns seem superfluous and redundant against each > other, since we really can't load Engineer rows without querying all > three tables. In that sense it takes on all the limitations of > concrete table inheritance, which doesnt use a "type" column at the > table level. > after a night's sleep, let me backtrack a bit.having discriminiator columns in all superclass tables would probably still be effective in the way we use discriminiator columns right now. the mapper would basically have to use one or the other in the case where more than one is available (like, querying subclasses of Engineer). You would want to share the primary key column across all three tables though (i.e. foreign key in the subclass table, like the link I mentioned) so that the primary key takes on the same form no matter what class you're looking at - that helps inheritance a great deal since its one of the assumptions SQLA makes. The change to SA's internals would still be pretty heavy and its hard to say what kinds of roadblocks would appear when developing such a feature. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "sqlalchemy" group. To post to this group, send email to sqlalchemy@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sqlalchemy?hl=en -~--~~~~--~~--~--~---
[sqlalchemy] Re: Multiple Inheritance
i went for polymorphic asociation on my multiple inheritances /
multiple aspects. it gives even more freedom than what strict
inheritance needs.
the examples around ruby-on-rails are for one2many/many2one:
http://wiki.rubyonrails.org/rails/pages/UnderstandingPolymorphicAssociations
sqlalchemy/examples/poly_assoc/
i have a many2many version,
http://dbcook.svn.sourceforge.net/viewvc/dbcook/trunk/dbcook/usage/polymassoc.py
the idea: the assoc.table points to the value and to all the possible
owners (via foreign keys), with only one of the owners set-up for
each record. this can probably be extended to point to multiple types
of values too.
ciao
svil
On Thursday 04 September 2008 06:25:53 Michael Bayer wrote:
> On Sep 3, 2008, at 8:47 PM, Sam Magister wrote:
> > I was wondering if it is possible to set up joined table
> > inheritance so that a subclass inherits from more than one base
> > table. To extend the example given in the documentation, we would
> > have a base class 'Employee' and a base class 'Citizen' such that
> > an 'Engineer' would inherit from both Employee and Citizen
> > classes and have independent 'citizen_id' and 'employee_id'. One
> > could imagine other classes that only inherit from either
> > employee or citizen.
> >
> > employees = Table('employees', metadata,
> > Column('employee_id', Integer, primary_key=True),
> > Column('employee_type', String(30), nullable=False)
> > )
> >
> > citizens = Table('citizens', metadata,
> > Column('citizen_id', Integer, primary_key=True),
> > Column('citizen_type', String(30), nullable=False)
> > )
> >
> > An engineer who is both an employee and a citizen would have am
> > employee_id and a citizen_id:
> >
> > engineers = Table('engineers', metadata,
> > Column('id', Integer, primary_key=True)
> > Column('employee_id', Integer,
> > ForeignKey('employees.employee_id')),
> > Column('citizen_id', Integer,
> > ForeignKey('citizens.citizen_id')), Column('engineer_info',
> > String(50)),
> > )
>
> This pattern doesnt entirely make sense - the "citizen_type" and
> "employee_type" columns seem superfluous and redundant against each
> other, since we really can't load Engineer rows without querying
> all three tables. In that sense it takes on all the limitations of
> concrete table inheritance, which doesnt use a "type" column at the
> table level.
>
> Also, a key aspect of SQLA's polymorphic loading capability is that
> a mapper is aware of all of its possible subtypes. If multiple
> inheritance is part of that, the geometry of "what are all my
> subtypes?" becomes a more chaotic. We'd have to join to every
> table in the whole hierarchy to identify the type. To be fair I
> think this is a behavior that Hibernate supports but they only
> support it for single inheritance (and they also boast of how
> difficult it was to implement).SQLA's usual notion of "primary
> key" with respect to joined table inheritance wouldn't work here
> either (engineer's PK is either (x, y) or (x, y, z), employee and
> citizen are just (x)), suggesting again a more "concrete" notion -
> you need to select from the subclass table in order to locate the
> object, and the primary key itself does not provide enough
> information to select the appropriate subclass table.
>
> The standard patterns for "multiple" inheritance in SQL are listed
> at
> http://www.agiledata.org/essays/mappingObjects.html#MappingMultiple
>Inheritance . There you'll find examples of concrete, single, and
> joined table "multiple" inheritance.
>
> You can certainly map to any of the hierarchies indicated in that
> article, but you wouldn't be able to take advantage of SQLA's
> "polymorphic" capabilities, which are designed to only handle
> single inheritance. You'd really want to make your
> Engineer(Employee, Citizen) class and just map it to
> engineers.join(citizens).join(employees). That would get your
> schema going, just without SQLA having any awareness of the
> "inheritance" portion of it, and is extremely similar to a plain
> concrete setup, which is pretty much all you'd get anyway without
> the ability to load polymorphically.
>
> > For my application, this pattern is important (the above example
> > is only an example of the pattern, I'm not really modeling
> > employees and citizens) and I was wondering if anyone had any
> > suggestions as to how to go about implementing this
> > functionality, which I'm planning on doing.
>
> if you mean "implementing" within SQLAlchemy itself such that its
> core notion of inheritance is modified to support multiple base
> classes spread across multiple tables, this would be an enormously
> difficult feature to implement.For polymorphic loading, at the
> very least SQLA would need to lose its dependency on
> "discriminator" columns and learn to just look for row presence in
> a table as evidence of belonging to a certain type (that alone is
> not necessarily a bad thing, as Hibernate does this too).
>
> It would also
[sqlalchemy] Re: Multiple Inheritance
On Sep 3, 2008, at 8:47 PM, Sam Magister wrote:
>
> I was wondering if it is possible to set up joined table inheritance
> so that a subclass inherits from more than one base table. To extend
> the example given in the documentation, we would have a base class
> 'Employee' and a base class 'Citizen' such that an 'Engineer' would
> inherit from both Employee and Citizen classes and have independent
> 'citizen_id' and 'employee_id'. One could imagine other classes that
> only inherit from either employee or citizen.
>
> employees = Table('employees', metadata,
> Column('employee_id', Integer, primary_key=True),
> Column('employee_type', String(30), nullable=False)
> )
>
> citizens = Table('citizens', metadata,
> Column('citizen_id', Integer, primary_key=True),
> Column('citizen_type', String(30), nullable=False)
> )
>
> An engineer who is both an employee and a citizen would have am
> employee_id and a citizen_id:
>
> engineers = Table('engineers', metadata,
> Column('id', Integer, primary_key=True)
> Column('employee_id', Integer,
> ForeignKey('employees.employee_id')),
> Column('citizen_id', Integer, ForeignKey('citizens.citizen_id')),
> Column('engineer_info', String(50)),
> )
This pattern doesnt entirely make sense - the "citizen_type" and
"employee_type" columns seem superfluous and redundant against each
other, since we really can't load Engineer rows without querying all
three tables. In that sense it takes on all the limitations of
concrete table inheritance, which doesnt use a "type" column at the
table level.
Also, a key aspect of SQLA's polymorphic loading capability is that a
mapper is aware of all of its possible subtypes. If multiple
inheritance is part of that, the geometry of "what are all my
subtypes?" becomes a more chaotic. We'd have to join to every table
in the whole hierarchy to identify the type. To be fair I think this
is a behavior that Hibernate supports but they only support it for
single inheritance (and they also boast of how difficult it was to
implement).SQLA's usual notion of "primary key" with respect to
joined table inheritance wouldn't work here either (engineer's PK is
either (x, y) or (x, y, z), employee and citizen are just (x)),
suggesting again a more "concrete" notion - you need to select from
the subclass table in order to locate the object, and the primary key
itself does not provide enough information to select the appropriate
subclass table.
The standard patterns for "multiple" inheritance in SQL are listed at
http://www.agiledata.org/essays/mappingObjects.html#MappingMultipleInheritance
. There you'll find examples of concrete, single, and joined table
"multiple" inheritance.
You can certainly map to any of the hierarchies indicated in that
article, but you wouldn't be able to take advantage of SQLA's
"polymorphic" capabilities, which are designed to only handle single
inheritance. You'd really want to make your Engineer(Employee,
Citizen) class and just map it to
engineers.join(citizens).join(employees). That would get your schema
going, just without SQLA having any awareness of the "inheritance"
portion of it, and is extremely similar to a plain concrete setup,
which is pretty much all you'd get anyway without the ability to load
polymorphically.
> For my application, this pattern is important (the above example is
> only an example of the pattern, I'm not really modeling employees and
> citizens) and I was wondering if anyone had any suggestions as to how
> to go about implementing this functionality, which I'm planning on
> doing.
if you mean "implementing" within SQLAlchemy itself such that its core
notion of inheritance is modified to support multiple base classes
spread across multiple tables, this would be an enormously difficult
feature to implement.For polymorphic loading, at the very least
SQLA would need to lose its dependency on "discriminator" columns and
learn to just look for row presence in a table as evidence of
belonging to a certain type (that alone is not necessarily a bad
thing, as Hibernate does this too).
It would also need to learn to create joins to other tables
corresponding to horizontal and vertical relationships, and be able to
guess the type of a row based on a complicated equation of row
presence. All of the ambigousness introduced by multiple inheritance,
like diamond patterns and such would also have to be dealt with.So
I'm not really sure that even with the best of efforts, multiple
inheritance could ever be nearly as transparent as single
inheritance. Beyond the effort level to implement, I'd be very
concerned about the complexity it would introduce to SQLA's
internals.The use case itself seems exceedingly rare. While a
recipe that "gets the job done" is entirely fine in this case, I'm
fairly skeptical of functionality like this as a core feature.
--~--~-~--~~
[sqlalchemy] Re: Multiple inheritance and relations
Michael Bayer wrote:
> On Apr 27, 2007, at 11:17 AM, Dave Harrison wrote:
>> Hi all,
>>
>> I've got a situation where I have a table of data that is common,
>> with the
>> subtables just adding an extra couple of fields. Using multiple
>> inheritance I
>> fit it together as below (pretty much the same as the documented
>> example).
>>
>> What I'm having problems with is then accessing those child tables
>> as properties
>> of the person table mapping. I'm get the following error,
>>
>> """
>> Cant determine relation direction for 'example' on mapper 'Mapper|
>> Person|person'
>> with primary join 'person.id = example.person_id' - foreign key
>> columns are not
>> present in neither the parent nor the child's mapped
>> tablesset([Column('person_id',Integer(),ForeignKey('person.id'))])
>> """
>>
>>
>
> the surprise here is that you established the relationship to the
> subclass, when the join condition is expressed in the superclass'
> table. theres all kinds of logic that is "limiting" the search for
> joins and foreign key relationships to between just the "local"
> tables (i.e. not to the joined inherited/inheriting tables) since we
> have a lot of test cases with very intricate self-referential
> relationships that blow up easily. so this innocent example led to
> the need to make all those searches look in both places separately
> and pick the one that fits better. this is in r2564.
>
>> P.S that error should read "foreign key columns are present in
>> neither ..."
>
> also in r2564.
Thanks Michael, much appreciated. By the way, congratulations on a fantastic
project.
Cheers
Dave
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"sqlalchemy" group.
To post to this group, send email to sqlalchemy@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/sqlalchemy?hl=en
-~--~~~~--~~--~--~---
[sqlalchemy] Re: Multiple inheritance and relations
On Apr 27, 2007, at 11:17 AM, Dave Harrison wrote:
>
> Hi all,
>
> I've got a situation where I have a table of data that is common,
> with the
> subtables just adding an extra couple of fields. Using multiple
> inheritance I
> fit it together as below (pretty much the same as the documented
> example).
>
> What I'm having problems with is then accessing those child tables
> as properties
> of the person table mapping. I'm get the following error,
>
> """
> Cant determine relation direction for 'example' on mapper 'Mapper|
> Person|person'
> with primary join 'person.id = example.person_id' - foreign key
> columns are not
> present in neither the parent nor the child's mapped
> tablesset([Column('person_id',Integer(),ForeignKey('person.id'))])
> """
>
>
the surprise here is that you established the relationship to the
subclass, when the join condition is expressed in the superclass'
table. theres all kinds of logic that is "limiting" the search for
joins and foreign key relationships to between just the "local"
tables (i.e. not to the joined inherited/inheriting tables) since we
have a lot of test cases with very intricate self-referential
relationships that blow up easily. so this innocent example led to
the need to make all those searches look in both places separately
and pick the one that fits better. this is in r2564.
> P.S that error should read "foreign key columns are present in
> neither ..."
also in r2564.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"sqlalchemy" group.
To post to this group, send email to sqlalchemy@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/sqlalchemy?hl=en
-~--~~~~--~~--~--~---
[sqlalchemy] Re: Multiple inheritance and Backrefs
Figured it out on my own :-)
You need the following for a mapper:
...
properties = { ...
'forks':relation(Fork,
secondary=UtensileTable,
primaryjoin=PlaceSetting.c.id==UtensileTable.c.placeSettingID,
secondaryjoin=UtensileTable.c.id==ForkTable.c.id,
backref=backref("placeSetting",
remote_side=[UtensileTable.c.id]),
)
...
enjoy
-percious
On Apr 13, 11:51 am, "percious" <[EMAIL PROTECTED]> wrote:
> I am trying to do something like this:
>
> PlaceSettingTable = Table("place_setting", metadata,
> Column('id', Integer, primary_key=True)
> )
>
> UtensileTable = Table("utensile", metadata,
> Column('id', Integer, primary_key=True),
> Column('name', Unicode(256)),
> Column('placeSettingID', Integer,
> ForeignKey('place_setting.id'))
> )
>
> ForkTable = Table("fork", metadata,
> Column('id', Integer, ForeignKey('utensile.id'),
> primary_key=True),
> Column('numberOfTines', Integer),
> )
> SpoonTable = Table("spoon", metadata,
> Column('id', Integer, ForeignKey('utensile.id'),
> primary_key=True),
> )
> KnifeTable = Table("knife", metadata,
> Column('id', Integer, ForeignKey('utensile.id'),
> primary_key=True),
> )
>
> class PlaceSetting(object):pass
> class Utensile(object):pass
> class Fork(object):pass
> class Knife(object):pass
> class Spoon(object):pass
>
> utensileMapper = mapper(Utensile, UtensileTable)
> forkMapper = mapper(Fork, ForkTable, inherits=utensileMapper)
>
> placeSettingMapper = mapper(PlaceSetting, PlaceSettingTable,
> properties={'forks':relation(Fork,
>
> primaryjoin=PlaceSettingTableTable.c.id==Fork.c.placeSettingID,
>
> backref=backref("placeSetting", remote_side=[UtensileTable.c.id]))
> }
> )
>
> unsuccessfully.
>
> Anyone have any ideas?
>
> -chris
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"sqlalchemy" group.
To post to this group, send email to [EMAIL PROTECTED]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/sqlalchemy?hl=en
-~--~~~~--~~--~--~---
