Re: [sqlalchemy] Deadlock in iterating over a session
Ok cool. I actually could write my code to produce exactly that effect fairly quickly since I was already accessing the mutable object through a comparable_property on the model. It was surprising how easy it was actually... SQLAlchemy really makes things awesome. We will start looking at moving to SQLAlchemy 0.7. It will probably be hard to convince people to move to a beta version on production systems though. When do you expect 0.7 to leave beta? I wonder if you could help with one other issue I have occationally observed that might be related to this. Sometimes of these mutable objects are None (myobject.value == None). These values are non-nullable columns in the database, and should always be represented as an actual class in logic. I have suspected this issue is related to objects being expired (by explicitly called session.expire()) and then detached from the session. But it seemed like SQLAlchemy should always either return a correct value or raise an exception. Returning None could result in incorrect behavor for code that does: if myobject.value: save_the_world(). Does it make sense that this would be happening? I think I saw documentation explaining that attribute values are loaded individually once they are expired? Could the resurrecting of state not be happening properly when only loading a single attribute? On Fri, Mar 4, 2011 at 2:16 PM, Michael Bayer mike...@zzzcomputing.comwrote: On Mar 4, 2011, at 5:09 PM, Lenza McElrath wrote: So there is no way to accomplish this in 0.6? I was looking at doing it the way I describe above, but it is not trivial to figure out which model/session a value is attached to. And I guess it is theoretically possible that a value could be connected to two models/sessions. Definitely scared of moving to an untested code... but looks like there are lots of improvements in 0.7 that might make it worth it... well, the on-change event required some less than trivial features so its an 0.7 thing. The best solution of all is to not use mutable types in the first place. I.e. if you need to change a scalar value in place, do something like myobject.value = value.mutate(xyz). -- You received this message because you are subscribed to the Google Groups sqlalchemy group. To post to this group, send email to sqlalchemy@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 sqlalchemy@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 sqlalchemy@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] Deadlock in iterating over a session
On Mar 6, 2011, at 8:16 PM, Lenza McElrath wrote: Ok cool. I actually could write my code to produce exactly that effect fairly quickly since I was already accessing the mutable object through a comparable_property on the model. It was surprising how easy it was actually... SQLAlchemy really makes things awesome. We will start looking at moving to SQLAlchemy 0.7. It will probably be hard to convince people to move to a beta version on production systems though. When do you expect 0.7 to leave beta? I wonder if you could help with one other issue I have occationally observed that might be related to this. Sometimes of these mutable objects are None (myobject.value == None). These values are non-nullable columns in the database, and should always be represented as an actual class in logic. I have suspected this issue is related to objects being expired (by explicitly called session.expire()) and then detached from the session. But it seemed like SQLAlchemy should always either return a correct value or raise an exception. Returning None could result in incorrect behavor for code that does: if myobject.value: save_the_world(). Does it make sense that this would be happening? I think I saw documentation explaining that attribute values are loaded individually once they are expired? Could the resurrecting of state not be happening properly when only loading a single attribute? expired attributes don't return None - they invoke a SELECT from the database when they are accessed, or raise an error (to the chagrin of many users) if the object is not associated with a session. I don't know offhand what would make your values come back as None, wondering what you mean by resurrecting, are you pickling the parent objects as well ? Without looking at the source I suppose that would be somewhat suspect though pickling/unpickling of mapped objects is well tested and supported. On Fri, Mar 4, 2011 at 2:16 PM, Michael Bayer mike...@zzzcomputing.com wrote: On Mar 4, 2011, at 5:09 PM, Lenza McElrath wrote: So there is no way to accomplish this in 0.6? I was looking at doing it the way I describe above, but it is not trivial to figure out which model/session a value is attached to. And I guess it is theoretically possible that a value could be connected to two models/sessions. Definitely scared of moving to an untested code... but looks like there are lots of improvements in 0.7 that might make it worth it... well, the on-change event required some less than trivial features so its an 0.7 thing. The best solution of all is to not use mutable types in the first place. I.e. if you need to change a scalar value in place, do something like myobject.value = value.mutate(xyz). -- You received this message because you are subscribed to the Google Groups sqlalchemy group. To post to this group, send email to sqlalchemy@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 sqlalchemy@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 sqlalchemy@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 sqlalchemy@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] Deadlock in iterating over a session
On Sun, Mar 6, 2011 at 5:21 PM, Michael Bayer mike...@zzzcomputing.comwrote: On Mar 6, 2011, at 8:16 PM, Lenza McElrath wrote: Ok cool. I actually could write my code to produce exactly that effect fairly quickly since I was already accessing the mutable object through a comparable_property on the model. It was surprising how easy it was actually... SQLAlchemy really makes things awesome. We will start looking at moving to SQLAlchemy 0.7. It will probably be hard to convince people to move to a beta version on production systems though. When do you expect 0.7 to leave beta? I wonder if you could help with one other issue I have occationally observed that might be related to this. Sometimes of these mutable objects are None (myobject.value == None). These values are non-nullable columns in the database, and should always be represented as an actual class in logic. I have suspected this issue is related to objects being expired (by explicitly called session.expire()) and then detached from the session. But it seemed like SQLAlchemy should always either return a correct value or raise an exception. Returning None could result in incorrect behavor for code that does: if myobject.value: save_the_world(). Does it make sense that this would be happening? I think I saw documentation explaining that attribute values are loaded individually once they are expired? Could the resurrecting of state not be happening properly when only loading a single attribute? expired attributes don't return None - they invoke a SELECT from the database when they are accessed, or raise an error (to the chagrin of many users) if the object is not associated with a session. I don't know offhand what would make your values come back as None, wondering what you mean by resurrecting, are you pickling the parent objects as well ? Without looking at the source I suppose that would be somewhat suspect though pickling/unpickling of mapped objects is well tested and supported. No pickling is happening. By resurrect I mean whatever is happening in MutableAttrInstanceState.__resurrect. I am definitely getting a None and not an error -- I happen to have an assert myobject.value is not None. I will try to make a test case. It is hard because I don't know exactly how to trigger this code path. I ran into an issues here before with mutable columns not being updated after resurrecting (fixed in r26f423a667ca). If I recall the test case I made for that it involved modifying the attribute in one function and then flushing the session in another. -- You received this message because you are subscribed to the Google Groups sqlalchemy group. To post to this group, send email to sqlalchemy@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.
