On Thu, Jan 08, 2004 at 04:56:40AM +0900, Francis Hwang wrote:
> As somebody who's done some of this work (I wrote Lafcadio), I
> strongly recommend that you consider extending somebody else's work
> before doing it yourself. When you enter this problem domain there are
> a lot of little wrinkles you run into, and the best solution isn't
> always necessarily obvious from the start.

Absolutely, I wouldn't want to write yet another database interface if I
could find one that suited me, with or without some modification. The
interface is not the point of this project.

> Now, I've only used Lafcadio, but I have the feeling that right now
> the Ruby OR-mapping tools out there are either 1) strong on mapping
> rows to objects, or 2) strong on ad-hoc querying, but not both.

This is my experience also, which is why I started this thread.

> I'd put Lafcadio and Vapor in category 1, and Criteria in category 2.

Criteria doesn't do any of category 1 at all, so yes.

> Either requirement is pretty big; both are twice as big. In the
> long-term, my feeling is that any library that sticks around in this
> space will have to satisfy both needs.

Uhuh. But none of them have quite cracked it yet.

> In the short-term, I can tell you what you'd have to do for Lafcadio
> to get it do what you want. First, Lafcadio was written first for
> MySQL, and although it should support Postgres with minimal changes, I
> have yet to implement or test such a change.

Vapor, to give an example, is very targeted at Postgres and uses a lot of its
more advanced features (in particular it integrates Postgres's
transaction model quite closely into its behaviour). Criteria, to give
another example, is running into problems because of subtly different
query syntaxes between different databases (MySQL's "RLIKE" vs
Postgres's "~", for example). Does Lafcadio suffer from either of these
constraints? In particular I'd like to have a fair bit of control over
when and where transactions are used - it's particularly critical in
cases like

"BEGIN;
   UPDATE accounts SET balance = balance - 100 WHERE accnum = 1743;
   UPDATE accounts SET balance = balance + 100 WHERE accnum = 329;
 COMMIT;"

If I were to do a similar thing in Ruby code, I'd need to be sure that
the account balance that I was using in the calculation was up-to-date
(otherwise the effects of someone else's transaction might get wiped)
and also that if the second UPDATE in the example above failed for some
reason then the first one would get rolled back. Can Lafcadio do, or be
made to do this?

> (At RubyConf Ryan Davis told me he was very interested in helping add
> Postgres functionality, and I moved the library to DBI to enable that,
> but I suspect that, like everybody else, Ryan's pretty busy.)

I am also interested in getting it to work with Postgres, if it solves
my problem. I'm pretty busy too, but I have time set aside for this
project that I can't really start on until I deal with this issue.

> Second, Lafcadio's support for querying works, but I'll be the first
> to admit that it's verbose and ugly as hell. Query inference is very
> high on my list, but then, I'm busy, too.  So Vapor or Criteria might
> be a better choice for you, depending.

I wouldn't consider Criteria to be in quite the same basket as Lafcadio
and Vapor. It doesn't have any OO abstraction at all (on the data side -
the project is all about OO abstraction of queries) I think Lafcadio (or
Vapor) could take a lot of ideas (and/or code) from Criteria for their
own query interfaces. I had independently thought of some of the
concepts behind Criteria when I discovered that somebody had already
written it, and in a much cleverer way than I would have thought of, but
it's not primarily a database interface library, it's a query
construction library. A project that combined the best aspects of the OO
data interfaces and the OO query interfaces that we already have would
be exactly what I was looking for.

Perhaps I'll start looking into how to a) get Lafcadio to work with
Postgres and b) get Lafcadio or Vapor to work with Criteria.

Tim Bates
-- 
tim / bates.id.au