On Feb 26, 8:53 pm, Myron Marston <[email protected]> wrote:
> > I haven't run it through the full test suite yet, but I don't expect
> > problems there. If anyone wants to review the diff and give me
> > feedback, I'd appreciate it.
>
> Looks good to me, but I don't know Sequel's code base at all. I do
> plan to try this out tomorrow at work. Should I respond here with
> feedback or do you have a pull request open on github to comment on or
> something?
Here with feedback would be great. I did fix a minor bug after I
posted that diff, where the arbitrary database connections weren't
being disconnected immediately after use (they'd probably be cleaned
up later by GC).
I'm going to be running the modified patch through the test suite, and
assuming no problems, it should be merged later today. I did some
light testing with it and found no issues, but as both of the specs
use mocked database connections, more real world testing would be
great.
> > 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.
> >> If you don't have a default DB that makes sense, then having
> >> a :default entry that raises an error is fine. You would probably
> >> want to set your default/shared options in the main connection string/
> >> options, and have the shards only override the parts they need.
> >> Putting it all together, this could possibly work for you currently:
>
> >> DB = Sequel.connect('postgres://user:password@host/db',
> >> :servers=>{:default=>proc{raise ...},
> >> ['host1', 'db1']=>{:host=>'host1', :database=>'db1'},
> >> ['host2', 'db2']=>{:host=>'host2', :database=>'db2'},
> >> ...})
>
> `Sequel.connect('postgres://user:password@host/db', ...` makes sense
> to me if `db` is valid database on `host`, and it's one you plan to
> use. In a case like mine, where all DB access will be through a
> particular shard...there isn't really a DB that makes sense to specify
> in the connection string. But I guess I just need to provide one, and
> then have the default option raise an error? It just seems like a
> semantically weird/confusing API to have to pass a valid connection
> string for a DB that I don't actually ever use. Not sure what (if
> anything) can/should be done about it, though.
Well, you don't have to provide a database in the connection string,
and you can use an options hash instead of a connection string and
just not provide the :database option. In either case, if you want an
error to be raised if no specific shard is given, the :default option
with the proc that raises will take care of that for you.
Thanks,
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.
