On May 10, 5:44 am, Jeremy Evans <[email protected]> wrote:
> On May 9, 5:38 pm, Stefan <[email protected]> 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?
>
> Subclass creation is when Sequel queries the database to get the
> column information for the model.  If the database connection isn't
> available, you won't be able to get the columns, and the column
> accessors won't be created.  It is possible to work around the issues
> later by changing the model's dataset, if you have at least a dummy
> database set up first.  Long story short, the modifications to have it
> not raise an error are not extensive, but I think raising an error is
> a better default, since otherwise we would have users that complained
> that they don't have column accessors for their models (which did
> happen before Sequel raised an error in this case).
>
>
>

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

>
>
> > > > 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?
>
> See above.
>
>
>
>
>
> > > > 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.
>
> 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,...).

>
> > > 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.

Anyway, thanks for your time.

<rest snipped>

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.

Reply via email to