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