On Thursday, April 26, 2012 12:58:57 PM UTC-7, Rodrigo Rosenfeld Rosas wrote:
> Actually I've learned about the sandbox version of the console today and I > found it very interesting. It would be great to be able to use it with > Sequel too. > That's fairly easy to do by adding an additional option to bin/sequel, and having IRB.start run inside a DB.transaction(:rollback=>:always) block. I haven't done it yet as it has corner cases (multiple threads and/or sharding, where a separate connection outside of the transaction could be created). > I don't think every block-based API should provide an alternative API, but > I don't see any issues in being able to manipulate connections and > transactions directly through a public API: > > conn = DB.pool.pop > conn.start_transaction > # then in other context that has a reference to conn: > conn.rollback_transaction # or conn.commit_transaction > conn.release > > It is up to the developer using such API to be sure connections won't leak. > This I don't agree with. The error handling for transactions is very complex, and few people would be able to get it correct. Providing a non-block based public API would encourage developers to use it, which they would probably do poorly, things would break, and they would come here for support. I don't want to support that use case, it's just not worth it. Block-based APIs solve this issue so that developers don't have to worry about it. > This works like the File.open API: > > f = File.open(filename, 'w') > # f << ... > f.close > File.open(filename, 'w') do |f| > # f << ... > end > > I'm pretty sure most block-based API (threads, sockets, etc) provide an > alternative to the block-based approach. > > Opening and closing files is fairly simple compared to database transactions, and still, when the non-block form is used, you'll often see problems where errors are not handled correctly. Good ruby style uses the block-based API so that errors are handled correctly. Even your non-block code has an obvious bug where the File instance is not be closed if an exception is raised. > Why should it be different with Sequel? > I don't want to encourage anyone to write code that will lead to problems in exceptional situations. Listen, I understand where you are coming from, but the book is shut on this. If you want a non-block based API, I've given you all the tools you need to add one yourself. Just don't expect me to support it. Jeremy -- You received this message because you are subscribed to the Google Groups "sequel-talk" group. To view this discussion on the web visit https://groups.google.com/d/msg/sequel-talk/-/2UcXr3d1nRkJ. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/sequel-talk?hl=en.
