> * 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.
That make sense. I didn't realize that a reference would be kept to the DB object outside of any variables I use. > * 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. Agreed. This was more of a hack than anything else. I figured you might have something better in mind :). > 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. If it's not too much trouble to add, I can also imagine needing/ wanting an API to set the the default shard to use for all subsequent DB queries (or is that already present?). Within the sinatra application, I imagine we'll always use the block API but I can imagine other cases (such as one-off rake tasks) where we'd want to just set the shard at the start and not worry about wrapping everything in a block. > 2) The ability to use arbitrary shards instead of pre-defined shards. Yep, this was the main thing that I couldn't figure out how to do with the documented sharding API. > 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. With this approach, how would Sequel handle it when a shard hasn't been set? I would like it to raise an error since there is no default shard that makes sense. > 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 think disconnecting once the shard I'm done using the shard is the only thing that makes sense. That said: what are the performance implications of needing to connect and disconnect to a different DB shard for each request? I can (and will) benchmark if necessary, but I figured you might have a typical ballpark number for how long those operations take :). > 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 That API looks great. One question, though: how do I get the DB object? Presumably through `Sequel.connect`, but I'm not sure what connection string I would pass, given that there's not default DB that makes sense. I'm impressed at how quickly you responded and that you're willing to add features to meet our needs so quickly--thanks! That said, bear in mind that it's not definite that we'll use Sequel yet. We're evaluating it at the moment. I'm definitely leaning strongly towards it but the fact that we all have ActiveRecord experience (and, in my case, a good 4-5 years of it), and none of us have Sequel experience, counts for a lot. Thanks again! Myron -- 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.
