On Thursday, April 26, 2012 3:41:26 PM UTC-7, Rodrigo Rosenfeld Rosas wrote: > > Em 26-04-2012 18:44, Jeremy Evans escreveu: > > 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). > > > Rails console is not just an IRB instance. It loads the Rails environment > and will make some other variables and methods available to the console. > What is bin/sequel all about? >
Well, it depends on what you mean by "not just an IRB instance". By default, it does call IRB.start: https://github.com/rails/rails/blob/master/railties/lib/rails/commands/console.rb Doing transaction{console.start} would be a perfectly valid way to implement the sandbox. bin/sequel refers to sequel's command line tool. If you've installed the sequel gem, just run "sequel" on the command line. It's mentioned near the top of the README. > > > 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. > > > So, what? Those people will never search for such methods. It is more > likely that they will only use the block-based API. The additional API > would be only used for special cases usually. In such cases, like RSpec or > Rails console, leaking isn't a real problem and the implementation is so > trivial that it would never leak. > You would be surprised how often people will use an inferior tool even if a superior tool is available. If you think an implementation is so trivial it would not cause problems, I think you are wrong. Let's say you lost your database connection in the middle of your spec (someone kill -9 the wrong process), what do you think would happen? Possibly: connection pool removes connection, new connection for next spec (not in a transaction!). Running each spec in it's own transaction fixes this issue. Note I think that may be a general problem with your idea of using a transaction around all the specs and a savepoint for each individual spec. > I think it is a mistake to try to hide complexity from developers. They > should be given the choice and should be able to understand the pros and > contras of each approach and then make the decision. You're not responsible > for other's mistake. > You are entitled to your own opinion. However, in my opinion much of good programming is hiding the underlying complexity from developers. You would be surprised how often I get asked to help fix other people's mistakes. I may not be responsible, but that doesn't mean it wouldn't take up time better spent doing other things. > Providing a non-block based public API would encourage developers to use > it, > > > Why do you think so? Just state in the API documentation: > > "WARNING: We really advice you against the use of such methods. It is very > hard to prevent connections from leak if you're not using the block-based > approach. In some rare situations (like interacting with other badly > designed software) it is necessary to have this kind of control. But please > don't use this unless you absolutely know what you're doing. You've been > warned!" > > Then, only adventurers or cautions developers would use such an API. > > With the current situation, only such developers will do what you are proposing. Basically, I like the current situation. The people smart enough to implement it properly can do so themselves, anyone who needs someone else to write a public API for them probably wouldn't be able to implement it properly. > 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. > > > Then add to the notes that those methods aren't officially supported. :) > If it isn't officially supported, it shouldn't be added at all. You already have code that does what you want and isn't officially supported. > Block-based APIs solve this issue so that developers don't have to > worry about it. > > > But it also leaves other issues opened. > > This remembers me a recent discussion in the ruby-core list where some > core developers think that thread-programming is too complicate for users > to make it correctly. So they don't bother in providing a virtual machine > that will allow you to use the full power of your CPUs when running > multi-threaded code due to a global lock. They say that you can get more > CPU power by using processes instead and that dealing with locks by > yourself while programming IPC can be too dangerous and they want a simpler > approach for Ruby users. Clearly I don't agree with this complexity hiding > policy. > I'm with the ruby developers. I think process-based design is the correct approach, and threads should only be used when absolutely necessary. Virtually all threaded code has race conditions in it. Anyone following the sequel commit log can see just this month I've been fixing issues with Sequel's thread safety that only occur on non-GVL ruby implementations (such as JRuby). > 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. > > You can't know that, there is only a comment between the open and close > methods :) > Interrupt 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/-/MzoxN_mhuOsJ. 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.
