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 <[email protected]> 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 [email protected].
> > To unsubscribe from this group, send email to
> > [email protected].
> > 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 [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/sqlalchemy?hl=en.
