[sqlalchemy] Re: Lazy loading advantages and disadvantages
Adam M Peacock wrote: Is there a difference in the SQL executed when using lazy vs eager loading? Specifically, if I use eager loading will everything be queried at once with a more efficient join, or will it still use the lazy style (as far as I understand it) of generating a ton extra queries as it loads each relation separately? If it is the former, more efficient case (an eager relation uses a join) is it possible to override the loader type at query time, such as being lazy by default but being nice to the database when I know I'm going to need all the data from the relation (especially if I'm calling a couple thousand rows for a report)? Eager loads are performed using a join, so only a single query is issued. You can change the eager/lazy behaviour at query time by using the 'options' method on the query object. See http://www.sqlalchemy.org/docs/datamapping.myt#datamapping_selectrelati ons_eagerload and http://www.sqlalchemy.org/docs/datamapping.myt#datamapping_selectrelati ons_options for more. Hope that helps, Simon --~--~-~--~~~---~--~~ 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: references to polymorphic concrete-inheritance
FYI, polymorphic associations to concrete mappings are totally unsupported in Hibernate, an ORM that has a lot more maturity, widespread usage, and developers on it than this one...leaving me fairly uninspired to worry much about SA's similar limitations with polymorphic concrete mappings (even though SA has a better chance of supporting them, since we support mappings to unions). http://www.hibernate.org/hib_docs/reference/en/html/ inheritance.html#inheritance-strategies concrete mappings and A-B-C-D inheritance doesnt strike me as very high priority at this pointwhat im becoming interested in from hibernate at this point is its ability to issue multiple SELECTs for one query, for polymorphic loading as well as immediate relationship loading. thats of more generalized usage than SA's reliance upon UNION and elaborate LEFT OUTER JOINs. that's all ok, i don't want u to do it, i want to know a how it can be done - if i ever need it. Anyway i cannot use concrete polymorphic stuff now, so i don't use it. But i do use table-inheritance, and there are some things there that do not work - or at least the way i'm using SA does not work. See the other mail about lazy-reference to polymorphic mappers; seems to me the select issued for lazy-load is wrong: SELECT pu_b.db_id AS pu_b_db_id, pu_b.name AS pu_b_name, pu_b.linkA_id AS pu_b_linkA_id, pu_b.atype AS pu_b_atype, pu_b.dataC AS pu_b_dataC, pu_b.dataB AS pu_b_dataB FROM ( SELECT C.db_id AS db_id, A.name AS name, A.linkA_id AS linkA_id, A.atype AS atype, C.dataC AS dataC, B.dataB AS dataB FROM A JOIN B ON B.db_id = A.db_id JOIN C ON C.db_id = B.db_id UNION ALL SELECT bz4B.db_id AS db_id, bz4B.name AS name, bz4B.linkA_id AS linkA_id, bz4B.atype AS atype, CAST(NULL AS TEXT) AS dataC, bz4B.dataB AS dataB FROM ( SELECT A.linkA_id AS linkA_id, A.name AS name, A.db_id AS db_id, A.atype AS atype, B.dataB AS dataB FROM A JOIN B ON B.db_id = A.db_id WHERE A.atype = ? ) AS bz4B ) AS pu_b WHERE pu_b.linkA_id = pu_b.db_id ORDER BY pu_b.oid IMO the last WHERE would need a second FROM entry but it has only one?? On Feb 21, 2007, at 3:02 PM, [EMAIL PROTECTED] wrote: id use an association table with its own entity to make things easy. hm, u mean... A.link references that table by single id, and the table contains the tuple (discriminator,id) ? But isn't this another sort of table-inheritance? looks like a join to me... not that i'm big specialist on joins. And how to automate the secondary loadby(discriminator,id)? On Feb 21, 2007, at 10:05 AM, svilen wrote: g'day. How one can make such thing as a reference to concrete-inherited polymorphic mapper? e.g. if there are just two, A and B, B inherits A, both have full concrete tables. A has polymorphic mapper. If both tables have separate primary ids, they will overlap as values - table_A.id=1 for some A() and table_B.id=1 for some B() are both ok; hence, query(A).getby_id(1) would return 2 objects via the polymorphic union. in this case, the unique key within the polymunion seems to be the id+type_discriminator; where type_discriminator effectively means this id is from that table. i see 2 possibilities here: - use 2-field key: a tuple of discriminator(table_name) and id-in-that-table. How would one make references to those objects then? e.g. what would be the definition of Column( 'mylink_id', ...) be ? it becomes a link to multiple tables... Would the propertyLoaders support such multi-column key? or make some constructed single key instead? - use one common sequence for filling both primary-keys of both tables. But this is limited to DBs which support sequences... Any help? ciao svil --~--~-~--~~~---~--~~ 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: unexpected exception
On Feb 22, 6:04 am, Manlio Perillo [EMAIL PROTECTED] wrote: Michael Bayer ha scritto: its what it says...its updating the database and not finding the rows it expects, indicating some other concurrent process already deleted that row. Is this actually possible, even if each query run in its own transaction? The database is Postgresql 8.1, Debian Etch. sure...its a deleted row so row locking doesnt even countboth transactions can occur totally separate from each other too. --~--~-~--~~~---~--~~ 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] suggestion to use deferrable foreign key constraints
Are there any plans to handle circular dependencies by using deferrable foreign key constraints when available? In my case, I had made the foreign key constraints deferred, but SQLAlchemy didn't pick up on that when I reflected the database metadata. I eliminated the circular dependency by using post_update=True, but that meant dropping a NOT NULL constraint since postgres can't defer those (sigh). --~--~-~--~~~---~--~~ 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: Error with Self Referential Tutorial
try putting primaryjoin=... inside the backref() I've been trying to recreate the self referential 'parent/child' mapper tutorial: http://www.sqlalchemy.org/docs/adv_datamapping.myt#advdatamapping_s elfreferential I keep getting the following error: Error determining primary and/or secondary join for relationship 'TreeNode.parent (TreeNode)'. I updated to 0.3.5 and have been digging through the archives trying different 'remote_side' combinations and keep getting the same error. Any help would be greately appreciated! -A --~--~-~--~~~---~--~~ 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: suggestion to use deferrable foreign key constraints
ive heard of foreign key constraints that dont take effect until the tranasction actually commits, but I have never actually seen this in practice. which databases support this feature ? i didnt think it was so common (though not surprised PG supports it). On Feb 22, 2007, at 1:15 PM, Luke Stebbing wrote: Are there any plans to handle circular dependencies by using deferrable foreign key constraints when available? In my case, I had made the foreign key constraints deferred, but SQLAlchemy didn't pick up on that when I reflected the database metadata. I eliminated the circular dependency by using post_update=True, but that meant dropping a NOT NULL constraint since postgres can't defer those (sigh). --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---