Fantastic, I will like to look into this change. Since you asked, consider a use case similar to this: we have a RESTfulish web service that accepts a serialized version of a "transfer object" which is passed to the server when a database save should take place. In this case, an "order" with select relations are serialized and passed.
For a database save, this will be added to the session after it is "cast" into a sqlalchemy object. Nothing special there. Now for the use case: the webservice needs to also be invoked while the user is still working on the order. For example, taxes and delivery charges are calculated by the server. Again, the serialized version of the transfer object is sent to the server and cast into a sqlalchemy object. In this case, however, we have no intention on ever saving the object during this service request. Rather, the sqlalchemy object is transient. Still, to calculate taxes as an example there are a handful of relations that need to be loaded, such as zipcode objects, tax authorities, tax tables, etc. The reason for not wanting to disable autoflush is that this same code is (appropriately) invoked whether this object is persistent (from merge()) and part of the save web service or transient and part of the calculate web service (where the object is going to be thrown away). In the case of being the save, it is important for database consistency thar autoflush remain enabled. In either case, if zipcodeid is the local side of fk join to load the zipcode relation, you would expect that a reference like: orderobj.zipcode would load the zipcode object since zipcodeid is populated, whether orderobj is transient or persistent. Since sqla won't load that for me in the case of transient, I need to load the relation manually (unless you feel like enhancing that as well). Now I can manually emulate the obj being persistent with your changes for On Sep 6, 2010, at 10:58 AM, Michael Bayer <mike...@zzzcomputing.com> wrote: > > On Sep 6, 2010, at 9:06 AM, Kent wrote: > >> with_parent seems to add a join condition. > > OK, so I guess you read the docs which is why you thought it joined and why > you didn't realize it doesn't work for transient. r20b6ce05f194 changes all > that so that with_parent() accepts transient objects and will do the "look at > the attributes" thing. The docs are updated as this method does use the > lazy loader SQL mechanism, not a join. > > > >> Is there a way to get at >> the query object that would be rendered from a lazy load (or what >> "subqueryload" would render on the subsequent load), but on a >> transient object, if i supply the session? >> >> even though not "recommended", can it make sqla believe my transient >> object is detached by setting its state key? >> >> There are reasons i do not want to add this to the session and >> disabling autoflush would also cause problems. >> >> >> >> On Sep 3, 9:58 am, Michael Bayer <mike...@zzzcomputing.com> wrote: >>> On Sep 3, 2010, at 9:36 AM, Kent wrote: >>> >>>> For the case of customerid = '7', that is a simple problem, but when >>>> it is a more complex join condition, we only wanted to define this >>>> condition in one single place in our application (namely, the orm). >>>> That way, if or when that changes, developers don't need to search for >>>> other places in the app that needed to manually duplicate the logic of >>>> the orm join condition. >>> >>>> If I supplied the DBSession to sqla, it would know how to create the >>>> proper Query object for this lazyload. Can you point me in the right >>>> direction (even if where you point me is not currently part of the >>>> public API)? >>> >>> Query has the with_parent() method for this use case. >>> >>> >>> >>> >>> >>>> Thanks again, >>>> Kent >>> >>>> -- >>>> You received this message because you are subscribed to the Google Groups >>>> "sqlalchemy" group. >>>> To post to this group, send email to sqlalch...@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 sqlalch...@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. >> > > -- > You received this message because you are subscribed to the Google Groups > "sqlalchemy" group. > To post to this group, send email to sqlalch...@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. > -- You received this message because you are subscribed to the Google Groups "sqlalchemy" group. To post to this group, send email to sqlalch...@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.
