[sqlalchemy] Re: pairing merged object with the original
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.
Re: [sqlalchemy] Re: pairing merged object with the original
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 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.
[sqlalchemy] Re: pairing merged object with the original
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.
[sqlalchemy] Re: pairing merged object with the original
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
Re: [sqlalchemy] Re: pairing merged object with the original
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.
Re: [sqlalchemy] Re: pairing merged object with the original
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 are the same. I'm not sure though why you arent using the attributes.get_history() function I showed you which would allow you to see anything that changed directly. seems a lot simpler than what you're trying to do. 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? Yeah looking at the source its actually wholesale replacing the list on the target object so its a direct copy. I had the notion that it was appending to the list but I was incorrect. 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
[sqlalchemy] Re: pairing merged object with the original
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 is the point of merge in the first place? you can assume the lengths are the same. I'm not sure though why you arent using the attributes.get_history() function I showed you which would allow you to see anything that changed directly. seems a lot simpler than what you're trying to do. I am using this handy function, actually, and I could explain why, in this case, I need more, but that is really a whole more discussion (in short, the original object has some plain python attributes I need to read which merge() does not copy for me because the are not mapper properties, so I need a reference to the original object) 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? Yeah looking at the source its actually wholesale replacing the list on the target object so its a direct copy. I had the notion that it was appending to the list but I was incorrect. Thanks. 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
