Re: [sqlalchemy] Hang while committing to sqlite db using ironpython
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I'd recommending strace'ing your process to see what syscall causes the hang. On 08/02/2013 02:49 PM, Michael Bayer wrote: never been tested on IronPython. On Aug 1, 2013, at 11:18 PM, Agus Wang tiduzf...@gmail.com mailto:tiduzf...@gmail.com wrote: I've tested on python 2.7.3 with SQLAlchemy 0.8.2 and it works fine I think the problem is the ironpython, is sqlalchemy compatible with ironpython? On Thursday, August 1, 2013 5:56:36 PM UTC+7, Agus Wang wrote: I'm using ironpython 2.7.3 and sqlalchemy(0.7.10) on my windows environment I've set up the database in sqlite using sqlalchemy declarative syntax, this works fine But when I try to save some data to the db using commit() My program suddenly hang but the actual data has been saved to the db This is what the debug looks like 2013-08-01 17:38:19,239 DEBUG sqlalchemy.pool.NullPool Created new connection Connection object at 0x0046 2013-08-01 17:38:19,521 DEBUG sqlalchemy.pool.NullPool Connection Connection object at 0x0046 checked out from pool 2013-08-01 17:38:19,531 INFO sqlalchemy.engine.base.Engine BEGIN (implicit) ...the sql command.. 2013-08-01 17:38:20,185 INFO sqlalchemy.engine.base.Engine COMMIT 2013-08-01 17:38:20,212 DEBUG sqlalchemy.pool.NullPool Connection Connection object at 0x0046 being returned to pool 2013-08-01 17:38:20,222 DEBUG sqlalchemy.pool.NullPool Closing connection Connection object at 0x0046 Somehow it's stuck in here. -- You received this message because you are subscribed to the Google Groups sqlalchemy group. To unsubscribe from this group and stop receiving emails from it, send an email to sqlalchemy+unsubscr...@googlegroups.com mailto:sqlalchemy+unsubscr...@googlegroups.com. To post to this group, send email to sqlalchemy@googlegroups.com mailto:sqlalchemy@googlegroups.com. Visit this group at http://groups.google.com/group/sqlalchemy. For more options, visit https://groups.google.com/groups/opt_out. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.20 (GNU/Linux) iQEcBAEBAgAGBQJR+7V1AAoJEJuEULkdE2LBXIMIAJnBKWpO3Q+xNzwI6qUdFVMK RQODuOZPC8y9/N2qNBYJNlNj8nJsmzEWdZ0T8EvENMXf7swPnwPACclji5ATLUqH jR/33UDhCiTQFi0PYFY4zxqys/8LsZ2uB6tFHKjgykVBRgizx5QrjEkNBCrQdXlk HkYa6o7JLf6jRMX1Co93PuQLgr/WD3q2Olt/p7hJcOhxd06bKMGpEoycm22GFfXk FH4z8QWyflWIQbqJ6rvT9PY/QtdNUO/EF04Zv/90/ks+BQ16Aa0x01YMxtwbKiUb BRVeewcUwJiTDZJKhKbGOK05XkKp+aSkZGe28OzNHUvk2EBKiIiiZ6mn+TIbs6s= =JD9V -END PGP SIGNATURE- -- You received this message because you are subscribed to the Google Groups sqlalchemy group. To unsubscribe from this group and stop receiving emails from it, send an email to sqlalchemy+unsubscr...@googlegroups.com. To post to this group, send email to sqlalchemy@googlegroups.com. Visit this group at http://groups.google.com/group/sqlalchemy. For more options, visit https://groups.google.com/groups/opt_out.
[sqlalchemy] Find out what's going to be deleted
When using more complex, hierarchical models with differing settings on how cascade deletes are handled it gets quite hard to figure out beforehand what a delete() will exactly do with the database. I couldn't find any way to get this piece of information (Hey SQLAlchemy, what will be deleted if I delete that object over there?) from SQLAlchemy. Implementing this by myself doesn't really seem like an option since this would result sooner or later in situations where my prediction and the actual consequences of the delete() differ, which would be very… unpleasant for the user. (This question was also posted on SO: http://stackoverflow.com/q/16875605/675646 ) -- You received this message because you are subscribed to the Google Groups sqlalchemy group. To unsubscribe from this group and stop receiving emails from it, send an email to sqlalchemy+unsubscr...@googlegroups.com. To post to this group, send email to sqlalchemy@googlegroups.com. Visit this group at http://groups.google.com/group/sqlalchemy?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
Re: [sqlalchemy] Find out what's going to be deleted
Thanks a lot for your comprehensive answer! I was able to solve my problem by implementing your first suggestion. Orphans do not play a role yet… I think :-) On 06/02/2013 05:09 PM, Michael Bayer wrote: The only deletes that aren't present in session.deleted before the flush are those that will occur because a particular object is an orphan, and the objects which would be deleted as a result of a cascade on that orphan. So without orphans taken into account, session.deleted tells you everything that is to be deleted. To take orphans into account requires traversing through all the relationships as the unit of work does, looking for objects that are currently orphans (there's an API function that will tell you this - if the object is considered an orphan by any attribute that refers to it with delete-orphan cascade, it's considered an orphan), and then traversing through the relationships of those orphans, considering them to be marked as deleted, and then doing all the rules again for those newly-deleted objects. The system right now is implemented by orm/dependency.py. It is probably not hard to literally run a unit of work process across the session normally, but just not emit the SQL, this would give you the final flush plan. But this is an expensive process that I wouldn't want to be calling all the time. A feature add is difficult here because the use case is not clear.Knowing what will be deleted basically requires half the flush process actually proceed. But you can already implement events inside the flush process itself, most directly the before_delete() and after_delete() events that will guaranteed catch everything.So the rationale for a new feature that basically runs half the flush, before you just do the flush anyway and could just put events inside of it, isn't clear. On Jun 2, 2013, at 9:46 AM, pub...@enkore.de wrote: When using more complex, hierarchical models with differing settings on how cascade deletes are handled it gets quite hard to figure out beforehand what a delete() will exactly do with the database. I couldn't find any way to get this piece of information (Hey SQLAlchemy, what will be deleted if I delete that object over there?) from SQLAlchemy. Implementing this by myself doesn't really seem like an option since this would result sooner or later in situations where my prediction and the actual consequences of the delete() differ, which would be very… unpleasant for the user. (This question was also posted on SO: http://stackoverflow.com/q/16875605/675646 ) -- You received this message because you are subscribed to the Google Groups sqlalchemy group. To unsubscribe from this group and stop receiving emails from it, send an email to sqlalchemy+unsubscr...@googlegroups.com. To post to this group, send email to sqlalchemy@googlegroups.com. Visit this group at http://groups.google.com/group/sqlalchemy?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
