On Dec 9, 2:07 pm, Chuck Remes <[email protected]> wrote: > I recently submitted a patch to allow for shards to be dynamically > added to the connection pool at runtime. It's working well.
That's good to hear. I have a working patch for remove_server and disconnecting active connections, I just didn't have time to commit it today. Hopefully I'll have a change to commit it tomorrow. > Now I have a new use case where I need to modify a schema on a shard, > but I don't know how I can do that. The only way to address a shard > directly is through Dataset#server which obviously doesn't allow any > calls to #alter_table (or others). You should not be using the sharding support to modify schema on specific shards. Anything with different schemas or modifying schemas should be using different Database objects (mentioned near the top of http://sequel.rubyforge.org/rdoc/files/doc/sharding_rdoc.html). > I can get to the correct database shard by using the > Sequel:Database#synchronize call, but it yields (in my case) a > Java::OrgH2Jdbc::JdbcConnection. I can't use any of the nice schema > generator calls on that object (it's a Java object). > > Is it possible for me to go from a JdbcConnection object back to a > Sequel:Database reference? If you called DB.synchronize to get the connection object, then DB is the Sequel::Database object you are looking for. > Is there another way to address a database shard without going through > Sequel:Dataset? As you already know, the argument you pass to DB.synchronize determines which shard to use. > Ideally, I would like to be able to do something like this: > > shards = #some hash > DB = Sequel.connect "jdbc:h2:master_server", :servers => shards > .... > DB.server(some_shard_id).create_table :test do > .. > .. > end Nope, the design isn't set to work like that. This might work: def DB.execute_ddl(sql, opts={}, &block) super(sql, {:server=>some_shard_id}.merge(opts), &block) end All schema-modifying methods should go through execute_ddl. > Alternately, if there was a way for me to capture the ddl output by > the schema methods, I could call #execute on the connection (attained > through #synchronize) and pass in the DDL. Is it possible to get the > DDL from a #create_table block? Internally, there is create_table_sql, but the APIs for the database schema sql generation methods are private. That's not because they are dangerous to use, but because I want the freedom to change the internals without breaking a public API. They are all documented though, so if you want to look at the lib/sequel/database/schema_*.rb files, you can probably figure it out. > I've been looking through the code for hours but I can't find any way > of accomplishing this task. I thought I might be able to mimic the > behavior of Sequel:Dataset and just clone the Sequel:Database object > while passing in my specified shard server, but the clone > functionality isn't present in Sequel:Database. (And I don't know if > it is safe to use Object#clone on the Sequel:Database to do this work.) No, Sequel::Database was not designed with the same functional-style API. Actually, Sequel itself was not designed for sharding at all. Sharding came fairly late in development (v2.4.0). > Any suggestions would be welcome. I'm not sure why you want to run schema methods on specific shards, but the execute_ddl override is probably the best way to do it. Personally, I'd just make a connection to a single shard using a separate database object: Sequel.connect("jdbc:h2:shard1") do |db| db.create_table(:test){...} end 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.
