From: Jeff Davis <ruby@...>
Date: 2008-09-26T12:08:56+09:00
Subject: Re: How to make Ruby _THE_ scripting language of choice, fold in	SQLite

On Fri, 2008-09-26 at 08:43 +0900, John Carter wrote:
> The fact is the function call notation is insufficiently rich to
> specify an arbitary SQL statement without reducing to the (very)
> lowest common denominator (string) and then invoking a (heavyweight)
> SQL interpretor.

I suggest you look at Sequel http://sequel.rubyforge.org/

This isn't just an ORM or DBI style layer. This is using Ruby syntax to
form relational expressions with an SQL flavor.

The python equivalent is SQLAlchemy.

These are really using the right approach, they do not try to map some
not-very-well-defined object model onto SQL, they just offer a SQL-ish
language inside of Ruby that generates real SQL, and sends it off for
evaluation.

> Suggestion to make Ruby the undisputed leader of the scripting languages...
>    1) Extend Ruby syntax to accept a useful subset of SQLite SQL.

SQLite is pretty far from the SQL standard, last time I checked. I don't
consider it the pinnacle of database semantics.

>    2) incorporate the appropriate bits of SQLITE into the Ruby
>       interpretor to evaluate it.

You haven't shown why _any_ of this needs to be in the interpreter
itself. What are you trying to accomplish, and why can't you accomplish
it through Ruby's rich extensibility?

>    3) and perhaps optionally generate string queries for
>       (mysql/postgres/oracle...) backends.

What is the language you're trying to use for this purpose, and how is
this simpler than current systems that can generate strings to send to
SQL DBMSs?

>    4) provide a means of transparently mapping certain classes to
>       tables so that they are automagically persisted at commit points,
>       on garbage collection or program exit, and automagically
>       revivified on reference.

The devil is in the details. "Automagically"? Is it more automagical
than current solutions like AR?

What about constraints and concurrency? These automagical persistence
engines tend to have difficulty in a centralized environment unless your
data is 100% semantically independent.

>    5) Hide the distinction between Object "handles" and foreign
>       keys. ie. If instance variable @c of an object of class A is
>       a reference to an instance of class / table C, then
>       following that reference may cause that row of table C to be
>       looked up and revivified as an instance of class C.

You're not the first person to have thought of this. The problem is,
there _is_ a distinction between those two concepts, and for good
reason. 

What about a summary object, that represents the result of some GROUP BY
query? What is the object ID of that, and what is the database key?

> # Attaches, unless told otherwise to sqlite db __FILE__.db

What about ruby code that's not stored in a file?

The code example you gave looks pretty much like every other ORM. How is
yours fundamentally different, aside from not being able to connect to a
remote server?

Regards,
	Jeff Davis