On Feb 10, 2010, at 4:28 PM, Kent wrote:

> Very good, thanks.
> 
> Although, I'm pretty sure I understand what you are saying, what
> exactly do you mean by "pending/transients"?

see the description here:

http://www.sqlalchemy.org/docs/session.html#quickie-intro-to-object-states


> 
> 
> 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.
> 

-- 
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.

Reply via email to