On Sep 7, 2010, at 6:41 PM, Kent Bower wrote: > Two items: > > * How does the orm currently determine whether it is safe to try get() (e.i. > there are no "funny join conditions")? If you point me to the function where > decision takes place, I can probably answer this myself....
it compares the join condition of the relationship() to that of the clause which the Mapper uses when it issues get(), then stores that away as a flag for future consultation. It's very unusual for a many-to-one relationship to be based on something other than a simple foreign-key->primary key relationship, though. > > * When I build up the primary key from the foreign key, is there an > efficient way to build a composite key in the correct order to pass to get()? > (I thought maybe "synchronize_pairs", but that maybe has to do with > getting the direction consistent instead?) Well if you aren't using any composite primary keys in many-to-ones, you wouldn't even have to worry about this. Otherwise, the two collections to correlate would be property.local_remote_pairs and property.mapper.primary_key. Perhaps make a dictionary out of dict([(r, l) for l, r in prop.local_remote_pairs]) and your PK value would be [getattr(instance, prop.parent.get_property_by_column(mydict[p]).key) for p in property.mapper.primary_key]. Or if you want to get ambitious you can just copy roughly whats in strategies.py on line 605 but then you're digging into internals....and looking at that now I'm wondering if strategy._equated_columns is really different than local_remote_pairs at all... > > Thanks again, you've been much help! > > > > On 9/7/2010 5:03 PM, Michael Bayer wrote: >> >> >> 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. > > > -- > 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.
