On Sep 7, 2010, at 4:38 PM, Kent Bower wrote: > Don't want to strangle me, but when the orm (lazy)loads a MANYTONE object, it > doesn't go to the database if the object is in the session. Can I get > "with_parent()" to behave this way, or would I need to specifically build up > the primary key of the related object and call query.get()?
the latter. You can use get() for all many to ones if you aren't using any funny join conditions. > > > > On 9/7/2010 10:25 AM, Michael Bayer wrote: >> >> >> On Sep 7, 2010, at 10:12 AM, Kent Bower wrote: >> >>> Mike, in your proof of concept, when __getstate__ detected transient, why >>> did you need to make a copy of self.__dict__? "self.__dict__.copy()" >> >> i was modifying the __dict__ from what would be expected in a non-serialized >> object, so that was to leave the original object being serialized unchanged. >> >>> >>> >>> >>> On 9/6/2010 2:35 PM, Michael Bayer wrote: >>>> >>>> On Sep 6, 2010, at 2:11 PM, Kent Bower wrote: >>>> >>>>> Also, I was hoping you would tell me whether this would be a candidate >>>>> for subclassing InstrumentedAttribute? Would that make more sense or >>>>> providing custom __getstate__ & __setstate__ ? >>>> __getstate__ / __setstate__ are pretty much what I like to use for pickle >>>> stuff, unless some exotic situation makes me have to use __reduce__. One >>>> problem with the recipe is that theres no 'deferred' loading of >>>> attributes. So in that sense playing with InstrumentedAttribute would >>>> give you a chance to put a callable in there that does what you want. >>>> >>>> There is also the possibility that __setstate__ can load up callables into >>>> the instance_state using state.set_callable(). This is a callable that >>>> triggers when you access the attribute that is otherwise None. There's a >>>> little bit of fanfare required to get that callable to assign to the >>>> attribute in the right way. Attached is an example of that. This is >>>> all a little more shaky since the state/callable API isn't really public. >>>> Hasn't changed for awhile but there's no guarantee. >>>> >>>> >>>> >>>> >>>> >>>> >>>>> Thanks for your help, hopefully I'll be able to contribute such a recipe. >>>>> >>>>> Kent >>>>> >>>>> >>>>> >>>>>>> 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). >>>>>> its not an enhancement - it was a broken behavior that was specifically >>>>>> removed. The transient object has no session, so therefore no SQL can >>>>>> be emitted - there's no context established. >>>>>> >>>>>> >>>>>> >>>>>>> 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. >>>>>>> >>>>>> -- >>>>>> 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. >> >> -- >> 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.
