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?
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.
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.
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.
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. :)
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.
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.
That is why it would be used only for exceptional situations where it is
not possible to use the block-based approach.
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 :)
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.
Ok, got it, sorry for insisting.
--
You received this message because you are subscribed to the Google Groups
"sequel-talk" group.
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.
