On Feb 24, 11:20 am, Myron Marston <[email protected]> wrote:
> https://gist.github.com/1903020
>
> Essentially, the main API here is `DB.use_shard(host, db_name) { ... }
> `. Within the block, the appropriate shard is used for all queries;
> outside the block, a `NoCurrentShardError` will be raised. It
> accomplishes this by putting a delegate object in place of the
> assigned DB, and defining __getobj__ to return the real
> Sequel::Database object so that all method calls are delegated to
> that.
>
> Is this a sane approach to our sharding needs? Is there a better way
> to do this?
Here are the general issues I see with your code:
* It leaks Database objects. All database objects are stored in the
Sequel::DATABASES array, and if Sequel.connect isn't called with a
block, they need to be removed manually.
* It doesn't respect per-Database settings, since it creates new
Database objects for each shard.
* The usage of thread-local variables means that you can have only a
single Database object using the feature.
* From a design perspective, the functionality you want should be
handled at the connection pool level.
You are really asking for two separate things:
1) The ability to have a method that takes a block which sets the
default shard to use inside the block.
2) The ability to use arbitrary shards instead of pre-defined shards.
1) is fairly easy to address, requiring just a little refactoring so
that instead of defaulting to :default, it can default to the shard
set by the method. The main complication is that sometimes Sequel
uses :default as the server if no server is given, and there needs to
be a way to detect the difference between Sequel's use of :default and
a possible manual use of :default. I'll probably switch Sequel to
use :_sequel_default for the cases, so that it is easy to tell the
difference.
2) is not difficult to address in the simple case, but it causes other
questions, such as what to do with the connections for arbitrary
shards. I think the only way to handle arbitrary shards intelligently
is to remove the connection from the connection pool immediately after
it's usage is completed. I'll probably make it so that you can set
shard to an arbitrary hash that gets merged into the default database
options.
I plan to address both of these issues, hopefully before 3.33.0 is
released next week. Here's my planned API for your use case:
DB.with_server(:host=>'foo', :database=>'bar') do
# Will use host foo and database bar for connections inside the
block.
end
Thanks,
Jeremy
--
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.
