have you tried using query + join() + contains_eager() ?  any query you
like can be used to build the object graph of your choice along
relations().


bojanb wrote:
>
> Here's something I've been struggling with recently. I'll include the
> description of steps that got me here, as I believe the context will
> make the question clearer.
>
> It all started because I needed to show data (eg. in a list form) from
> two related tables (classes). However, SQLAlchemy would emit one SQL
> query for getting the objects of the first class, then one query each
> for each access to attributes of the other class. It obviously loads
> the attributes lazily, which is fine most of the time but grossly
> inefficient in this case (as there can be thousands of records in the
> first table).
>
> "Aha, I'll use eagerload!" I thought. Alas, it doesn't seem to work
> for inherited classes. A message in this group suggests that it
> doesn't work for self-referential inherited classes, but in this case
> it didn't work for plain inherited classes that don't contain
> references to self. I'll write a test case that shows this later.
>
> OK, I then decided to create a new class mapped against the two
> tables, using join() in a mapper. This worked great regarding the
> emitted SQL - session.query on new object generates the correct SQL
> even with the (deep) inheritance tree that we have. Modifying the
> attributes on of this object also writes them to correct respective
> tables on commit. Great! The new class even conceptually fits nicely
> with the rest of the application (e.g. I realized it's more of a
> business object while the two underlying classes/tables are more of an
> implementation detail; I'm not sure I even need the other two classes,
> just the tables may be enough). Fantastic!
>
> However, I can't figure how to create new instances of this (composite
> as I call it) class. Since it contains fields both for autogenerated
> primary key from the first class and foreign key from the second
> class, I cannot set the foreign key because I don't know the primary
> key before I commit, and commit fails because the foreign key is still
> null.
>
> Am I just missing something or am I attempting a no-no? I would think
> that since I've defined the attributes to be identical in the
> "oncluase", SQLAlchemy would now that the two are dependent and would
> not complain about the null value.
>
> Of course, I can always create the two other objects, but being able
> to do it this way fits much more nicely with the rest of the
> application.
> >
>


--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---

Reply via email to