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? 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? 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 at http://groups.google.com/group/sqlalchemy?hl=en.