Hi Stefan, It looks like you may be doing some ETL work with Sequel, as I am. Why not just use the underlying Sequel connections? Then call
DB[:table] and DB1[:table] What do the models give you that the datasets don't? I have preferred to keep the layer between databases as thin as possible. Don On May 9, 2010, at 5:38 PM, Stefan wrote: > > > On May 8, 6:42 pm, Jeremy Evans <[email protected]> wrote: >> On May 8, 4:07 am, Stefan <[email protected]> wrote: >> >>> Hello, >> >>> I have two questions. >> >>> First question: How can I subclass Sequel::Model without having DB >>> connection? >> >> You don't. Well, you can hack the internals and do so, but I won't >> support that. > > Why? > >> >>> When I do: >> >>> class ETLJobSchedule < Sequel::Model >>> ... >>> end >> >>> I get: >> >>> /Library/Ruby/Gems/1.8/gems/sequel-3.11.0/lib/sequel/model/base.rb: >>> 125:in `db': No database associated with Sequel::Model (Sequel::Error) >>> from /Library/Ruby/Gems/1.8/gems/sequel-3.11.0/lib/sequel/model/ >>> base.rb:191:in `inherited' >> >> That's by design. >> > > What is the reason for that? > > >>> I do not know DB connection at the time of Class *declaration* and I >>> would like to set it up later, for example like this: >> >>> ETLJobSchedule.set_dataset(@connecti...@etl_schedules_table]) >> >> The model class isn't usable until the database connection has been >> established. Connect to the database first, then load your model >> classes. >> >>> 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. > > >> 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. > >> However, sharding is more of a dataset feature, and while models have >> full support for sharding when retrieving records, there isn't any >> built in support for saving records to specific shards. It's probably >> not hard to add if you need it, though. >> >>> Two entry points for specifying connection are sufficient for me: one >>> factory method (that creates model instances) and method for selecting >>> objects (find). >> >>> Something like: >>> schedule = ETLJobSchedule.new_from_connection(@connection) >>> schedules = ETLJobSchedule.find_using_connection(@connection, ...) >> >> That's not how Sequel works. You don't deal with connection objects, >> and while Sequel does make them available if you need them for low >> level stuff, there's no Sequel methods that accept them as arguments. >> You can do something like: >> >> schedules = ETLJobSchedule.server(:shard_id).first(...) >> >> To retrieve schedules from a specific shard. >> >> However, the new_from_connection can't be duplicated without some >> small extensions. Currently you'd need to override Model#_insert >> (kind of large), but I'd be OK with refactoring so that you'd only >> need to override a new method like _insert_dataset. For updating and >> deleting records, you would have to override _update_dataset and >> _delete_dataset. The only issue there is that Sequel does not store >> which shard was used to retrieve the objects. For that you could use >> the tactical_eager_loading plugin, and call retrieved_by to get access >> to the dataset that was used to retrieve the object, and get the shard >> id to use in _update_dataset and _delete_dataset. >> > > See above: no sharding - just more different DBs. > >>> Something analogous to Core Data where you can have more object stores >>> for one object model. >> >> I'm not familiar with Core Data. >> > > It might be interesting to look at it, at least the architecture and > approach to certain functionalities. > > >> Anyway, hope this helps. If you have more questions, just respond. >> > > Yes, it helped. Thanks. > > Stefan > > -- > 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. > -- 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.
