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