I’d be happy to discuss your integration with Thrudb. Drop me a note.

Also, I live close to NYC. I can try and be there at your next meeting…

Thanks to you and Matt for your interest in Thrudb.

class Post

Thanks for your kind words about the talk-I’m a bit overwhelmed at how good the response has been.

Also, I’d suggest not bothering with validations and callbacks in ActiveDocument, and rather write them in ActiveModel, an extraction from ActiveRecord that I started on.

I’m gonna post mine to git and do a quick blog post. Hopefully we can meet later in irc/campfire/whatever and join forces :)

You could switch out MySQL with Postgresql with CouchDB with ThruDB with minimal changes to your models.

Of course there would be edge cases where you would have to write specific queries in Lucene syntax or SQL. How often do people use find_by_sql in Rails apps, though (actually, I really want to know this)?

Borrowing from your example above, do I really care about how the conditional should be structured here:

User.find(:all, :conditions => “login:’s*’ AND created_at :[20071201 TO 20080115]”)

I really just want to say find all users where the login starts with “s” that were created between dec 01 of last year and the 15th of this month.

Basically, I guess what I’m proposing is twofold:

1. something like ActiveRecord::Extensions for your ActiveDocument - this would be easier than a bigger abstraction layer and would help developers adopt DocDBs because it removes most of the need to learn lucene syntax. Joins are of course a more difficult issue that I would need to give more, serious, thought to.

2. my pie in the sky (heh) dream is the bigger abstraction layer of course, which would satisfy my above-expressed desire to be able to swap about data storage backends with minimal code changes or restructuring. Imagine realizing that you are using a RDBMS but would get better scaling, at a way cheaper cost, by switching to a DocDB system. Then, oh I don’t know, some need changes in the project and you realize, crap, I need MySQL for this.

Maybe this wouldn’t require a totally agnostic abstraction layer (as in a replacement for or AR & AD), but just an interface used in models that results in your application not really caring what your storage system is; a config parameter that specifies:

config.data_store = :active_record
config.data_store = :active_document

much like the current directive:
config.action_controller.session_store = :active_record_store

Something else just came to me - what if you continue using a DocDB system but switch from Lucene to something else, with a different query language syntax?

Anyway those are just my immediate thoughts. This is a really interesting endeavor and I’d love to hack away at it with you. We should figure out a good time to meet up with Paul Dix - he said next week after Wednesday was good for him I believe?

It’s a project to allow querying data sources using the Enumerable api.