?

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')
end

Use a specific database connection or pool

Connection = DBConnection.new(...)

class Post < DB(Connection, 'post')
end

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

Associations

class Post < DB('posts'); end

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

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

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.

Comments

( 2 comments — Leave a comment )
polyergic
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).
aredridel
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 )