On Feb 10, 6:59 pm, Michael Bayer <mike...@zzzcomputing.com> wrote: > On Feb 10, 2010, at 4:36 PM, Kent wrote: > > > Further, if I inspect the returned object *directly* after the call to > > merge(), then aren't I guaranteed any Relations with use_list=True > > have will have the same length, since that is the point of merge in > > the first place? > > you can assume the lengths are the same. I'm not sure though why you arent > using the attributes.get_history() function I showed you which would allow > you to see anything that changed directly. seems a lot simpler than what > you're trying to do. >
I am using this handy function, actually, and I could explain why, in this case, I need more, but that is really a whole more discussion (in short, the original object has some plain python attributes I need to read which merge() does not copy for me because the are not mapper properties, so I need a reference to the original object) > > > > That being the case, I can always simply correspond the merged index > > with the original instances, correct (regardless of whether it is a > > newly created object or was get()'ed from the database)? > > > Correct? > > Yeah looking at the source its actually wholesale replacing the list on the > target object so its a direct copy. I had the notion that it was appending > to the list but I was incorrect. > > Thanks. > > > On Feb 10, 4:28 pm, Kent <k...@retailarchitects.com> wrote: > >> Very good, thanks. > > >> Although, I'm pretty sure I understand what you are saying, what > >> exactly do you mean by "pending/transients"? > > >> On Feb 10, 4:13 pm, Michael Bayer <mike...@zzzcomputing.com> wrote: > > >>> On Feb 10, 2010, at 3:52 PM, Kent wrote: > > >>>> If I understand you correctly, you are saying > >>>> object.list[0] will always cause creation (or fetch) of merged.list[0] > >>>> object.list[1] will always cause creation (or fetch) of merged.list[1] > >>>> etc. > > >>>> There may be also more merged.list[2], [3], etc... > > >>>> Correct? > > >>>> This is the merge code 0.5.8: > > >>>> if self.uselist: > >>>> dest_list = [] > >>>> for current in instances: > >>>> _recursive[(current, self)] = True > >>>> obj = session._merge(current, dont_load=dont_load, > >>>> _recursive=_recursive) > >>>> if obj is not None: > >>>> dest_list.append(obj) > >>>> if dont_load: > >>>> coll = attributes.init_collection(dest_state, > >>>> self.key) > >>>> for c in dest_list: > >>>> coll.append_without_event(c) > >>>> else: > >>>> getattr(dest.__class__, > >>>> self.key).impl._set_iterable(dest_state, dest_dict, dest_list) > > >>>> Can I rely this implementation remaining ordered (deterministic), even > >>>> if it is re-written for optimization purposes or something? > > >>> as long as you're using lists for your relations' collection > >>> implementations there's no reason the order of pending/transients would > >>> change. The objects coming back from the DB are not deterministic unless > >>> you add order_by to your relation, but thats why i said process those > >>> separately. > > >>>> Also, I see that if obj is None, then dest_list.append() won't be > >>>> called, which would mess up my indexes. I am wondering is there a > >>>> more sure mechanism? Under what circumstances will obj be None? > > >>> There's no codepath I can see where that can be None and there's no test > >>> that generates a None at that point, I'm not really sure why that check > >>> is there. I'd want to dig back to find its origins before removing it > >>> but _merge() pretty explicitly doesn't return None these days. > > >>>> On Feb 10, 3:30 pm, Michael Bayer <mike...@zzzcomputing.com> wrote: > >>>>> On Feb 10, 2010, at 2:49 PM, Kent wrote: > > >>>>>> After merge() returns, is there a way for me to pair each object in > >>>>>> the returned merge_obj with the object it was created from? > > >>>>>> For example: > >>>>>> merged_obj = session.merge(object) > > >>>>>> At the top level, it is trivial, merged_obj was created because of the > >>>>>> instance "object" > > >>>>>> For single RelationProperties under the top level, it is fairly > >>>>>> simple, too. > > >>>>>> That is: > > >>>>>> merged.childattr was merged from object.childattr > > >>>>>> Where it falls apart I think is if the RelationProperty.use_list == > >>>>>> True > > >>>>>> merged.list came from object.list, but is there a way for me to > >>>>>> reference the original objects inside the list. > > >>>>>> Did merged.list[0] come from object.list[0] or object.list[1] or > >>>>>> object_list[2]? > > >>>>>> I particularly can't use the pk because it won't always be set (often > >>>>>> this will be a new record) > > >>>>>> Any suggestions? > > >>>>> the ordering of those lists (assuming they are lists and not sets) are > >>>>> deterministic, especially with regards to the pending objects that have > >>>>> been added as a result of your merge (i.e. the ones that wont have > >>>>> complete primary keys). I would match them up based on comparison of > >>>>> the list of instances that are transient/pending. > > >>>>>> -- > >>>>>> 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 > >>>> 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 > > 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.
