[sqlalchemy] Re: preserving uselist relation instances in a session.refresh()
Is it rude to ask why not disable the weakidentity map? Under the turbogears web framework, our Sessions only exist for the duration of the service call, and I am finding myself appending all these objects to a no_garbage_collect list that I am keeping on the session object anyway. Then the thought occurred if there are problems, maybe he would have deprecated disabling the weakidentity map... On Mar 4, 5:26 pm, Michael Bayer mike...@zzzcomputing.com wrote: Kentwrote: Thanks... that is very helpful. I could keep references to these. If I choose the apparently lazier route and set weak_identity_map=False, then does any other action besides explicitly expunging free this memory, such as when the session goes out of scope, I assume? Or do I need to carefully expunge them? don't disable theweakidentity map. just maintain your own collection of all the objects you care about. On Mar 4, 4:09 pm, Conor conor.edward.da...@gmail.com wrote: Conor wrote: Kentwrote: I agree I shouldn't care, so maybe there is another way to attack my problem. The reason I care is because I've extended the python object with some auxiliary information that I need. After the refresh() in this case, I still need access to that data that is tied to the object, but not present in the database (it is transient data). If sqla creates a new instance, I loose that data. Is there a better mechanism for doing that? You need to either manually keep strong references to each object that has the auxiliary information or disable theweakidentity map. See http://www.sqlalchemy.org/docs/05/session.html#frequently-asked-quest... or http://www.sqlalchemy.org/docs/05/session.html#frequently-asked-quest... for more information. That second link should behttp://www.sqlalchemy.org/docs/05/session.html#session-attributes. Oops. On Mar 4, 3:38 pm, Michael Bayer mike...@zzzcomputing.com wrote: refresh doesn't remove any objects from the session so its a matter of what is present in the session, not marked as dirty, and strongly referenced on the outside. if you're using refresh you shouldn't care about how it gets data back into the collection. Kentwrote: What's strange is that I can't recreate the problem on more simple stage. Every time I refresh() on the parent object, the list objects remain the same. In other words, *sometimes* it behaves as I hope it to (by apparently refreshing the list's objects) and *sometimes* if throws them out and creates new ones. The mystery to me is what determines when it will create new instances vs. refreshing the existing ones? On Mar 4, 3:24 pm, Michael Bayer mike...@zzzcomputing.com wrote: Kentwrote: If I use session.refresh(obj) to re-load an obj that has a one-to-many relational property, the objects in the list are *replaced* instead of *refreshed* if they already exist. Suppose department has a list of employees: suppose dept.employees = [ emp1, emp2 ] session.refresh(dept) the dept.employees list's elements are replaced with new objects instead of reusing those that existed and refreshing them. Is it possible to have those same objects re-used and simply refreshed instead of replaced? you can only turn off refresh-expire cascade, which will prohibit the operation from traveling into the child objects. the collection is still refreshed for obvious reasons, its one of the attributes on your mapped object. To achieve your specified behavior, use session.refresh() given as its second argument the set of attribute names which are safe to be reloaded completely (in this case the scalars). Then for each uselist attribute, iterate the collection of each and call the desired version of session.refresh() for those. This is an easy refresh() function to create in a generalized way by inspecting the class-level attributes of the incoming object. -- 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: preserving uselist relation instances in a session.refresh()
On May 1, 2010, at 10:18 AM, Kent wrote: Is it rude to ask why not disable the weakidentity map? Under the turbogears web framework, our Sessions only exist for the duration of the service call, and I am finding myself appending all these objects to a no_garbage_collect list that I am keeping on the session object anyway. Then the thought occurred if there are problems, maybe he would have deprecated disabling the weakidentity map... The strong map only exists because it took us a very long time to figure out how to to the weak map correctly, as there were two major technical challenges to fix. one was how to not lose dereferenced but dirty items, the other was how to avoid the creation of publically-inaccessible cycles between objects and those within their related collections. There's no problem with the strong map other than its a configuration switch that adds to potential confusion, and when in use now demands that the Session be used in a very specific way, else the program's memory usage will grow unbounded. The strong map also features a prune method that absolutely does not work outside of cPython. So to me its a section of mediocre and unnecessary code that I'd like to remove. I do make strong collections for certain loading patterns but I prefer it to be local to a particular set of things that I know will be dereferenced at the end of a method, rather than the whole session. There are also per-session result-caching patterns that are described in examples/beaker_caching which I will sometimes make use of - these have the advantage of caching the whole query execution and fetching procedure, not just the objects themselves, and is also something you set up per-query. Other than that if you truly need everything sent in via add(), merge() and query() to just not go away, I'd rather add an extra method to SessionExtension for that. after_attach() already gets things via add()/delete()/merge() so another method like after_load() would accomplish that for query(). then you could just stick a set() on the session that stores whatever is received. On Mar 4, 5:26 pm, Michael Bayer mike...@zzzcomputing.com wrote: Kentwrote: Thanks... that is very helpful. I could keep references to these. If I choose the apparently lazier route and set weak_identity_map=False, then does any other action besides explicitly expunging free this memory, such as when the session goes out of scope, I assume? Or do I need to carefully expunge them? don't disable theweakidentity map. just maintain your own collection of all the objects you care about. On Mar 4, 4:09 pm, Conor conor.edward.da...@gmail.com wrote: Conor wrote: Kentwrote: I agree I shouldn't care, so maybe there is another way to attack my problem. The reason I care is because I've extended the python object with some auxiliary information that I need. After the refresh() in this case, I still need access to that data that is tied to the object, but not present in the database (it is transient data). If sqla creates a new instance, I loose that data. Is there a better mechanism for doing that? You need to either manually keep strong references to each object that has the auxiliary information or disable theweakidentity map. See http://www.sqlalchemy.org/docs/05/session.html#frequently-asked-quest... or http://www.sqlalchemy.org/docs/05/session.html#frequently-asked-quest... for more information. That second link should behttp://www.sqlalchemy.org/docs/05/session.html#session-attributes. Oops. On Mar 4, 3:38 pm, Michael Bayer mike...@zzzcomputing.com wrote: refresh doesn't remove any objects from the session so its a matter of what is present in the session, not marked as dirty, and strongly referenced on the outside. if you're using refresh you shouldn't care about how it gets data back into the collection. Kentwrote: What's strange is that I can't recreate the problem on more simple stage. Every time I refresh() on the parent object, the list objects remain the same. In other words, *sometimes* it behaves as I hope it to (by apparently refreshing the list's objects) and *sometimes* if throws them out and creates new ones. The mystery to me is what determines when it will create new instances vs. refreshing the existing ones? On Mar 4, 3:24 pm, Michael Bayer mike...@zzzcomputing.com wrote: Kentwrote: If I use session.refresh(obj) to re-load an obj that has a one-to-many relational property, the objects in the list are *replaced* instead of *refreshed* if they already exist. Suppose department has a list of employees: suppose dept.employees = [ emp1, emp2 ] session.refresh(dept) the dept.employees list's elements are replaced with new objects instead of reusing those that existed and refreshing them. Is it possible to have those same objects re-used and simply refreshed instead of replaced? you
[sqlalchemy] Re: preserving uselist relation instances in a session.refresh()
If it is a feature you'd prefer to eventually get rid of, I will not use it. You are correct that not *everything* that is fetched do I need a strong ref to. You said: There's no problem with the strong map other than its a configuration switch that adds to potential confusion, and when in use now demands that the Session be used in a very specific way, else the program's memory usage will grow unbounded. My assumption is that the strong map exists on the session object? Further, when the session object is closed, these references are gone and this memory will be garbage-collected, correct? In other words, for my understanding, or others reading the list, in a framework where a session's life cycle only lasted as long as a web service call, the threat of the program's memory growing unbounded is non-existent, correct? Kent -- 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: preserving uselist relation instances in a session.refresh()
On May 1, 2010, at 12:41 PM, Kent wrote: If it is a feature you'd prefer to eventually get rid of, I will not use it. You are correct that not *everything* that is fetched do I need a strong ref to. You said: There's no problem with the strong map other than its a configuration switch that adds to potential confusion, and when in use now demands that the Session be used in a very specific way, else the program's memory usage will grow unbounded. My assumption is that the strong map exists on the session object? Further, when the session object is closed, these references are gone and this memory will be garbage-collected, correct? In other words, for my understanding, or others reading the list, in a framework where a session's life cycle only lasted as long as a web service call, the threat of the program's memory growing unbounded is non-existent, correct? correct Kent -- 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: preserving uselist relation instances in a session.refresh()
What's strange is that I can't recreate the problem on more simple stage. Every time I refresh() on the parent object, the list objects remain the same. In other words, *sometimes* it behaves as I hope it to (by apparently refreshing the list's objects) and *sometimes* if throws them out and creates new ones. The mystery to me is what determines when it will create new instances vs. refreshing the existing ones? On Mar 4, 3:24 pm, Michael Bayer mike...@zzzcomputing.com wrote: Kent wrote: If I use session.refresh(obj) to re-load an obj that has a one-to-many relational property, the objects in the list are *replaced* instead of *refreshed* if they already exist. Suppose department has a list of employees: suppose dept.employees = [ emp1, emp2 ] session.refresh(dept) the dept.employees list's elements are replaced with new objects instead of reusing those that existed and refreshing them. Is it possible to have those same objects re-used and simply refreshed instead of replaced? you can only turn off refresh-expire cascade, which will prohibit the operation from traveling into the child objects. the collection is still refreshed for obvious reasons, its one of the attributes on your mapped object. To achieve your specified behavior, use session.refresh() given as its second argument the set of attribute names which are safe to be reloaded completely (in this case the scalars). Then for each uselist attribute, iterate the collection of each and call the desired version of session.refresh() for those. This is an easy refresh() function to create in a generalized way by inspecting the class-level attributes of the incoming object. -- 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: preserving uselist relation instances in a session.refresh()
refresh doesn't remove any objects from the session so its a matter of what is present in the session, not marked as dirty, and strongly referenced on the outside. if you're using refresh you shouldn't care about how it gets data back into the collection. Kent wrote: What's strange is that I can't recreate the problem on more simple stage. Every time I refresh() on the parent object, the list objects remain the same. In other words, *sometimes* it behaves as I hope it to (by apparently refreshing the list's objects) and *sometimes* if throws them out and creates new ones. The mystery to me is what determines when it will create new instances vs. refreshing the existing ones? On Mar 4, 3:24 pm, Michael Bayer mike...@zzzcomputing.com wrote: Kent wrote: If I use session.refresh(obj) to re-load an obj that has a one-to-many relational property, the objects in the list are *replaced* instead of *refreshed* if they already exist. Suppose department has a list of employees: suppose dept.employees = [ emp1, emp2 ] session.refresh(dept) the dept.employees list's elements are replaced with new objects instead of reusing those that existed and refreshing them. Is it possible to have those same objects re-used and simply refreshed instead of replaced? you can only turn off refresh-expire cascade, which will prohibit the operation from traveling into the child objects. the collection is still refreshed for obvious reasons, its one of the attributes on your mapped object. To achieve your specified behavior, use session.refresh() given as its second argument the set of attribute names which are safe to be reloaded completely (in this case the scalars). Then for each uselist attribute, iterate the collection of each and call the desired version of session.refresh() for those. This is an easy refresh() function to create in a generalized way by inspecting the class-level attributes of the incoming object. -- 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. -- 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: preserving uselist relation instances in a session.refresh()
I agree I shouldn't care, so maybe there is another way to attack my problem. The reason I care is because I've extended the python object with some auxiliary information that I need. After the refresh() in this case, I still need access to that data that is tied to the object, but not present in the database (it is transient data). If sqla creates a new instance, I loose that data. Is there a better mechanism for doing that? On Mar 4, 3:38 pm, Michael Bayer mike...@zzzcomputing.com wrote: refresh doesn't remove any objects from the session so its a matter of what is present in the session, not marked as dirty, and strongly referenced on the outside. if you're using refresh you shouldn't care about how it gets data back into the collection. Kent wrote: What's strange is that I can't recreate the problem on more simple stage. Every time I refresh() on the parent object, the list objects remain the same. In other words, *sometimes* it behaves as I hope it to (by apparently refreshing the list's objects) and *sometimes* if throws them out and creates new ones. The mystery to me is what determines when it will create new instances vs. refreshing the existing ones? On Mar 4, 3:24 pm, Michael Bayer mike...@zzzcomputing.com wrote: Kent wrote: If I use session.refresh(obj) to re-load an obj that has a one-to-many relational property, the objects in the list are *replaced* instead of *refreshed* if they already exist. Suppose department has a list of employees: suppose dept.employees = [ emp1, emp2 ] session.refresh(dept) the dept.employees list's elements are replaced with new objects instead of reusing those that existed and refreshing them. Is it possible to have those same objects re-used and simply refreshed instead of replaced? you can only turn off refresh-expire cascade, which will prohibit the operation from traveling into the child objects. the collection is still refreshed for obvious reasons, its one of the attributes on your mapped object. To achieve your specified behavior, use session.refresh() given as its second argument the set of attribute names which are safe to be reloaded completely (in this case the scalars). Then for each uselist attribute, iterate the collection of each and call the desired version of session.refresh() for those. This is an easy refresh() function to create in a generalized way by inspecting the class-level attributes of the incoming object. -- 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. -- 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: preserving uselist relation instances in a session.refresh()
Kent wrote: I agree I shouldn't care, so maybe there is another way to attack my problem. The reason I care is because I've extended the python object with some auxiliary information that I need. After the refresh() in this case, I still need access to that data that is tied to the object, but not present in the database (it is transient data). If sqla creates a new instance, I loose that data. Is there a better mechanism for doing that? You need to either manually keep strong references to each object that has the auxiliary information or disable the weak identity map. See http://www.sqlalchemy.org/docs/05/session.html#frequently-asked-questions or http://www.sqlalchemy.org/docs/05/session.html#frequently-asked-questions for more information. -Conor On Mar 4, 3:38 pm, Michael Bayer mike...@zzzcomputing.com wrote: refresh doesn't remove any objects from the session so its a matter of what is present in the session, not marked as dirty, and strongly referenced on the outside. if you're using refresh you shouldn't care about how it gets data back into the collection. Kent wrote: What's strange is that I can't recreate the problem on more simple stage. Every time I refresh() on the parent object, the list objects remain the same. In other words, *sometimes* it behaves as I hope it to (by apparently refreshing the list's objects) and *sometimes* if throws them out and creates new ones. The mystery to me is what determines when it will create new instances vs. refreshing the existing ones? On Mar 4, 3:24 pm, Michael Bayer mike...@zzzcomputing.com wrote: Kent wrote: If I use session.refresh(obj) to re-load an obj that has a one-to-many relational property, the objects in the list are *replaced* instead of *refreshed* if they already exist. Suppose department has a list of employees: suppose dept.employees = [ emp1, emp2 ] session.refresh(dept) the dept.employees list's elements are replaced with new objects instead of reusing those that existed and refreshing them. Is it possible to have those same objects re-used and simply refreshed instead of replaced? you can only turn off refresh-expire cascade, which will prohibit the operation from traveling into the child objects. the collection is still refreshed for obvious reasons, its one of the attributes on your mapped object. To achieve your specified behavior, use session.refresh() given as its second argument the set of attribute names which are safe to be reloaded completely (in this case the scalars). Then for each uselist attribute, iterate the collection of each and call the desired version of session.refresh() for those. This is an easy refresh() function to create in a generalized way by inspecting the class-level attributes of the incoming object. -- 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: preserving uselist relation instances in a session.refresh()
Conor wrote: Kent wrote: I agree I shouldn't care, so maybe there is another way to attack my problem. The reason I care is because I've extended the python object with some auxiliary information that I need. After the refresh() in this case, I still need access to that data that is tied to the object, but not present in the database (it is transient data). If sqla creates a new instance, I loose that data. Is there a better mechanism for doing that? You need to either manually keep strong references to each object that has the auxiliary information or disable the weak identity map. See http://www.sqlalchemy.org/docs/05/session.html#frequently-asked-questions or http://www.sqlalchemy.org/docs/05/session.html#frequently-asked-questions for more information. That second link should be http://www.sqlalchemy.org/docs/05/session.html#session-attributes. Oops. On Mar 4, 3:38 pm, Michael Bayer mike...@zzzcomputing.com wrote: refresh doesn't remove any objects from the session so its a matter of what is present in the session, not marked as dirty, and strongly referenced on the outside. if you're using refresh you shouldn't care about how it gets data back into the collection. Kent wrote: What's strange is that I can't recreate the problem on more simple stage. Every time I refresh() on the parent object, the list objects remain the same. In other words, *sometimes* it behaves as I hope it to (by apparently refreshing the list's objects) and *sometimes* if throws them out and creates new ones. The mystery to me is what determines when it will create new instances vs. refreshing the existing ones? On Mar 4, 3:24 pm, Michael Bayer mike...@zzzcomputing.com wrote: Kent wrote: If I use session.refresh(obj) to re-load an obj that has a one-to-many relational property, the objects in the list are *replaced* instead of *refreshed* if they already exist. Suppose department has a list of employees: suppose dept.employees = [ emp1, emp2 ] session.refresh(dept) the dept.employees list's elements are replaced with new objects instead of reusing those that existed and refreshing them. Is it possible to have those same objects re-used and simply refreshed instead of replaced? you can only turn off refresh-expire cascade, which will prohibit the operation from traveling into the child objects. the collection is still refreshed for obvious reasons, its one of the attributes on your mapped object. To achieve your specified behavior, use session.refresh() given as its second argument the set of attribute names which are safe to be reloaded completely (in this case the scalars). Then for each uselist attribute, iterate the collection of each and call the desired version of session.refresh() for those. This is an easy refresh() function to create in a generalized way by inspecting the class-level attributes of the incoming object. -- 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: preserving uselist relation instances in a session.refresh()
Thanks... that is very helpful. I could keep references to these. If I choose the apparently lazier route and set weak_identity_map=False, then does any other action besides explicitly expunging free this memory, such as when the session goes out of scope, I assume? Or do I need to carefully expunge them? On Mar 4, 4:09 pm, Conor conor.edward.da...@gmail.com wrote: Conor wrote: Kent wrote: I agree I shouldn't care, so maybe there is another way to attack my problem. The reason I care is because I've extended the python object with some auxiliary information that I need. After the refresh() in this case, I still need access to that data that is tied to the object, but not present in the database (it is transient data). If sqla creates a new instance, I loose that data. Is there a better mechanism for doing that? You need to either manually keep strong references to each object that has the auxiliary information or disable the weak identity map. See http://www.sqlalchemy.org/docs/05/session.html#frequently-asked-quest... or http://www.sqlalchemy.org/docs/05/session.html#frequently-asked-quest... for more information. That second link should behttp://www.sqlalchemy.org/docs/05/session.html#session-attributes. Oops. On Mar 4, 3:38 pm, Michael Bayer mike...@zzzcomputing.com wrote: refresh doesn't remove any objects from the session so its a matter of what is present in the session, not marked as dirty, and strongly referenced on the outside. if you're using refresh you shouldn't care about how it gets data back into the collection. Kent wrote: What's strange is that I can't recreate the problem on more simple stage. Every time I refresh() on the parent object, the list objects remain the same. In other words, *sometimes* it behaves as I hope it to (by apparently refreshing the list's objects) and *sometimes* if throws them out and creates new ones. The mystery to me is what determines when it will create new instances vs. refreshing the existing ones? On Mar 4, 3:24 pm, Michael Bayer mike...@zzzcomputing.com wrote: Kent wrote: If I use session.refresh(obj) to re-load an obj that has a one-to-many relational property, the objects in the list are *replaced* instead of *refreshed* if they already exist. Suppose department has a list of employees: suppose dept.employees = [ emp1, emp2 ] session.refresh(dept) the dept.employees list's elements are replaced with new objects instead of reusing those that existed and refreshing them. Is it possible to have those same objects re-used and simply refreshed instead of replaced? you can only turn off refresh-expire cascade, which will prohibit the operation from traveling into the child objects. the collection is still refreshed for obvious reasons, its one of the attributes on your mapped object. To achieve your specified behavior, use session.refresh() given as its second argument the set of attribute names which are safe to be reloaded completely (in this case the scalars). Then for each uselist attribute, iterate the collection of each and call the desired version of session.refresh() for those. This is an easy refresh() function to create in a generalized way by inspecting the class-level attributes of the incoming object. -- 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: preserving uselist relation instances in a session.refresh()
Kent wrote: Thanks... that is very helpful. I could keep references to these. If I choose the apparently lazier route and set weak_identity_map=False, then does any other action besides explicitly expunging free this memory, such as when the session goes out of scope, I assume? Or do I need to carefully expunge them? don't disable the weak identity map. just maintain your own collection of all the objects you care about. On Mar 4, 4:09 pm, Conor conor.edward.da...@gmail.com wrote: Conor wrote: Kent wrote: I agree I shouldn't care, so maybe there is another way to attack my problem. The reason I care is because I've extended the python object with some auxiliary information that I need. After the refresh() in this case, I still need access to that data that is tied to the object, but not present in the database (it is transient data). If sqla creates a new instance, I loose that data. Is there a better mechanism for doing that? You need to either manually keep strong references to each object that has the auxiliary information or disable the weak identity map. See http://www.sqlalchemy.org/docs/05/session.html#frequently-asked-quest... or http://www.sqlalchemy.org/docs/05/session.html#frequently-asked-quest... for more information. That second link should behttp://www.sqlalchemy.org/docs/05/session.html#session-attributes. Oops. On Mar 4, 3:38 pm, Michael Bayer mike...@zzzcomputing.com wrote: refresh doesn't remove any objects from the session so its a matter of what is present in the session, not marked as dirty, and strongly referenced on the outside. if you're using refresh you shouldn't care about how it gets data back into the collection. Kent wrote: What's strange is that I can't recreate the problem on more simple stage. Every time I refresh() on the parent object, the list objects remain the same. In other words, *sometimes* it behaves as I hope it to (by apparently refreshing the list's objects) and *sometimes* if throws them out and creates new ones. The mystery to me is what determines when it will create new instances vs. refreshing the existing ones? On Mar 4, 3:24 pm, Michael Bayer mike...@zzzcomputing.com wrote: Kent wrote: If I use session.refresh(obj) to re-load an obj that has a one-to-many relational property, the objects in the list are *replaced* instead of *refreshed* if they already exist. Suppose department has a list of employees: suppose dept.employees = [ emp1, emp2 ] session.refresh(dept) the dept.employees list's elements are replaced with new objects instead of reusing those that existed and refreshing them. Is it possible to have those same objects re-used and simply refreshed instead of replaced? you can only turn off refresh-expire cascade, which will prohibit the operation from traveling into the child objects. the collection is still refreshed for obvious reasons, its one of the attributes on your mapped object. To achieve your specified behavior, use session.refresh() given as its second argument the set of attribute names which are safe to be reloaded completely (in this case the scalars). Then for each uselist attribute, iterate the collection of each and call the desired version of session.refresh() for those. This is an easy refresh() function to create in a generalized way by inspecting the class-level attributes of the incoming object. -- 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: preserving uselist relation instances in a session.refresh()
Ok, I wonder the reasons, but I trust your answer completely, so I won't disable it. Thanks for your help again. On Mar 4, 4:26 pm, Michael Bayer mike...@zzzcomputing.com wrote: Kent wrote: Thanks... that is very helpful. I could keep references to these. If I choose the apparently lazier route and set weak_identity_map=False, then does any other action besides explicitly expunging free this memory, such as when the session goes out of scope, I assume? Or do I need to carefully expunge them? don't disable the weak identity map. just maintain your own collection of all the objects you care about. On Mar 4, 4:09 pm, Conor conor.edward.da...@gmail.com wrote: Conor wrote: Kent wrote: I agree I shouldn't care, so maybe there is another way to attack my problem. The reason I care is because I've extended the python object with some auxiliary information that I need. After the refresh() in this case, I still need access to that data that is tied to the object, but not present in the database (it is transient data). If sqla creates a new instance, I loose that data. Is there a better mechanism for doing that? You need to either manually keep strong references to each object that has the auxiliary information or disable the weak identity map. See http://www.sqlalchemy.org/docs/05/session.html#frequently-asked-quest... or http://www.sqlalchemy.org/docs/05/session.html#frequently-asked-quest... for more information. That second link should behttp://www.sqlalchemy.org/docs/05/session.html#session-attributes. Oops. On Mar 4, 3:38 pm, Michael Bayer mike...@zzzcomputing.com wrote: refresh doesn't remove any objects from the session so its a matter of what is present in the session, not marked as dirty, and strongly referenced on the outside. if you're using refresh you shouldn't care about how it gets data back into the collection. Kent wrote: What's strange is that I can't recreate the problem on more simple stage. Every time I refresh() on the parent object, the list objects remain the same. In other words, *sometimes* it behaves as I hope it to (by apparently refreshing the list's objects) and *sometimes* if throws them out and creates new ones. The mystery to me is what determines when it will create new instances vs. refreshing the existing ones? On Mar 4, 3:24 pm, Michael Bayer mike...@zzzcomputing.com wrote: Kent wrote: If I use session.refresh(obj) to re-load an obj that has a one-to-many relational property, the objects in the list are *replaced* instead of *refreshed* if they already exist. Suppose department has a list of employees: suppose dept.employees = [ emp1, emp2 ] session.refresh(dept) the dept.employees list's elements are replaced with new objects instead of reusing those that existed and refreshing them. Is it possible to have those same objects re-used and simply refreshed instead of replaced? you can only turn off refresh-expire cascade, which will prohibit the operation from traveling into the child objects. the collection is still refreshed for obvious reasons, its one of the attributes on your mapped object. To achieve your specified behavior, use session.refresh() given as its second argument the set of attribute names which are safe to be reloaded completely (in this case the scalars). Then for each uselist attribute, iterate the collection of each and call the desired version of session.refresh() for those. This is an easy refresh() function to create in a generalized way by inspecting the class-level attributes of the incoming object. -- 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.
