Log in

No account? Create an account

Previous Entry | Next Entry

A new ruby database API?

Use the 'user' table from the default connection or pool

class User < DB('user')

Use a specific database connection or pool

Connection = DBConnection.new(...)

class Post < DB(Connection, 'post')

That is, identify the database by a (reconnectable) connection to it.


class Post < DB('posts'); end

class User < DB('users')
	collection :posts, Post, :author # Optionally specifying remote key

class Post < DB('posts')
	reference :author, User

Collection associations return a collection object, not an array — it's enumerable, but will perform the fetch either lazily or eagerly, and has methods to force those. It could also take advantage of cursors for huge datasets.

All in all, it's like a low-magic, easy-to-debug ActiveRecord that I have in mind. I'd layer it on top of DBI, and go about cleaning that up and speeding it up where possible. I'd also love to see the low-level database APIs speak something that's directly usable as a DBI driver, and do type conversions in the database-specific and fastest way possible, preferably in C.

Queries by single field name and primary key should be easy. Maybe something like User.find(:name, 'John') or User.fetch(1)

Queries by join to an associated table should be possible. I'd love suggestions for an API. Dropping to SQL should only be needed for really complex cases, and be well-defined how the objects are derived from the result set. Replacing what's under the hood with something entirely unlike SQL should be possible and only break apps using SQL queries.

All of this makes me wish Ruby had a way to swap in a custom parser inline and then yield back to normal parsing at some place. Something that would allow User.find(name = 'John' and joindate < Date.today) — mixing in some Ruby syntax into a custom parser. I've some thoughts on how that could be done, but nothing coherent enough to stick in code.


( 2 comments — Leave a comment )
Mar. 10th, 2007 09:16 pm (UTC)
Nice. Especially with SPARQL.

For custom parsing, I've been thinking of having blocks that parse differently than their surroundings. (This comes from thinking about my grand scheme, wherein methods should be able to be written in any language.) Essentially, you have a block-opener-token that takes a parameter specifying which language, and only changing the language a little would be just as easy (you just need an identifier for the set of changes).
Apr. 8th, 2007 05:50 pm (UTC)
That's almost exactly my thought, though I'd switch parsers in a declaration, more than likely, so that the actual usage could flow as much as possible.

Something like parser SQL; rule statement: expr expr; rule expr: ...; end and then later def query(params = !!SQL); do sth with params as parsed; end

The biggest precursor to all this is a reified and first-class parser.
( 2 comments — Leave a comment )