On May 10, 1:06 am, Stefan <[email protected]> wrote: > On May 10, 5:44 am, Jeremy Evans <[email protected]> wrote: > > Thanks for explanation. I think I will go with DataMapper for this, > they have very elegant and simple solution: named connections > (repositories) and you use it like this: > > repository(:repository_name) { Person.first } > > http://datamapper.org/docs/misc
Sequel doesn't have a similar feature. The sharding feature could probably be abused to support something like that, but even then it would only work with the same database type. > > > > > Second question: How can I have model instances from different > > > > > connections? > > > > > You can have model classes with separate database connections: > > > > > class ModelA < Sequel::Model(DB1[:table1]) > > > > end > > > > > class ModelB < Sequel::Model(DB2[:table2]) > > > > end > > > > This is what I wanted to avoid. > > > Then you'll want to go with sharding. > > Definitely not :-) It is not the case. The manager should be able to > connect to any known and accessible (with special known connection > with required privileges) foreign database, which might be of any type > (mysql, postgres,...). You said earlier that all the databases have the same structure and different data. As long as the databases are the same type, Sequel's sharding feature should work for that. Sort of a moot point since you have different database types. > > > > The Sequel::Model method takes any dataset, so it's easy to specify > > > > that the model class should use a specific database by giving it a > > > > dataset from that database. > > > > > If you meant how to get two model instances from the same class to > > > > connect to different Database objects, you can't. > > > > > > Example situation: I have more DBs or DB schemas with a table with > > > > > same structure. How can I use Sequel::Model with more connections > > > > > where the same structure exist? > > > > > For that, look into Sequel's sharding > > > > functionality:http://sequel.rubyforge.org/rdoc/files/doc/sharding_rdoc.html > > > > In this case it is not about sharding. I simply have multiple separate > > > databases with same structure but different data and I want to manage > > > them from single point/application. > > > "Separate databases per customer" versus "sharding by customer" is a > > semantic argument I don't want to get into. I'll just state that > > Sequel's sharding functionality is useable in any case where you have > > multiple databases with the same schema. It works for master/slave > > databases, separate databases per customer, and traditional > > partitioning. > > See above. It is not single DB environment, it is set of environments > with different databases that I do not (and should not/do not have to) > have control of. Only thing I have available is a connection with > given privileges to the structures I want to control. I do not care > about rest of the DB. Even in the datamapper example you gave, you aren't providing a connection, merely a symbol specifying which connection to use. Sequel's sharding feature uses the same idea, where you specify the shard to use with a symbol. Other than having different database types (which you didn't mention earlier), the sharding feature would have worked assuming what you've said previously is true. Anyway, given you have different database types, the only real way to handle it in Sequel would be separate subclasses for each model for each database, using something like: CONNECTIONS = {:conn1=>Sequel.connect(...), :conn2=>Sequel.connection(...)} def repository(conn) begin Thread.current[:repo] = conn yield ensure Thread.current[:repo] = nil end end class Sequel::Model def self.sc self::REPOS[Thread.current[:repo]] end def self.setup_subclasses_for_databases h = {} CONNECTIONS.each do |k,v| c = Class.new(self) c.db = v h[k] = c end const_set(:REPOS, h) end end class ETLJobSchedule < Sequel::Model ... setup_subclasses_for_databases end repository(:conn1){ETLJobSchedule.sc.first} Not too ugly, but you'd have to add something similar to handle associations. Sequel wasn't designed with this use case in mind, and while you can get something similar, it's probably not going to be as easy as it would be with DataMapper, which has features specifically for this use case. 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.
