ActiveRecord filesystem based backend

Hi,

I hoping to find/write an ActiveRecord backend which stores each record
as a file in a directory, rather than as a row in a table in a database.
I'm not concerned about scaling or concurrency issues. My questions
are...

1) Does such a backend exist?
2) Is there some logical inconsistency between the behavior of
   ActiveRecord and the limits of a filesystem?
3) Where should implementation of such a backend begin? should I define
   an AbstractAdapter? or should I scrap ActiveRecord all together, and
   try to use another class as the base of my models?

In terms of what this would look like, I'm thinking that each record
would have a string id, which would serve as the file name, either a
single text field aside from the ID and would be equal to the entire
file contents, or allow for multiple attributes, and save them into the
file in the form of a YAML hash.

The use case which got me thinking of this was the desire to have an
rails application which users would often run locally on their own
machine, but with which they could share (active)records with other
users running other copies of the application on their machines. If the
records were saved as files, then

1) it would be easy for users to browse/inspect the records outside of
   the application
2) the sharing and merging of the records across instances could use
   some existing distributed VC system like GIT

the actual application could fairly easily wrap some simplifying UI
elements around something like git which could handle the pushing
pulling and merging of actual records between instances all the while
tracking who made what changes when.

Please don't hesitate to tell me if you think there are reasons why this
wouldn't/shouldn't work. Thanks -- Eric

What about searching/querying?

Hi Eric,

It’s pretty hard to write something like this using active record, 'cos it’s too easy to write complicated SQL code using it. How would you solve this issue? Would you write a query parser? A query optimizer? Build an indexing tool and also handle all the concurrency problems associated with such an effort?

You would end up writing a relational database, which doesn’t seem to be a great idea.

What you could do is write a simple persistence solution that “looks like” active record but using a simpler model (based on your ideas), removing all the SQL and things that resemble a relational database. You could take a look at ActiveResource and the way it behaves to get an idea about how you could build your API.

There's no reason you instead couldn't serialize the AR objects as XML
and just dump those files.

"Maurício Linhares" <mauricio.linhares@gmail.com> writes:

What you could do is write a simple persistence solution that "looks like"
active record but using a simpler model (based on your ideas), removing all the
SQL and things that resemble a relational database. You could take a look at
ActiveResource and the way it behaves to get an idea about how you could build
your API.

Hi Maurício,

Thanks for the suggestion. The problem with using something aside from
ActiveRecord is that you lose all of the view/form helpers, and (i
think) you also lose the has_many helper methods as well, so you'd
ultimately lose a large portion of the utility of the Rails framework.
It seems that IMO all of these helpers should be tied to a Module say
RailsModel or something which ActiveRecord, ActiveResource, etc... would
include. I don't know how if this would introduce too much indirection
into the Rails framework, but it would make it much easier to introduce
alternative storage mechanisms. I don't know much about Merb, but maybe
it already contains something similar?

Thanks -- Eric

If you write something that "looks like" active record, the view/form
methods woudn't change, but the association methods (has_one, has_many
and belongs_to) are something deeply rooted into active record and
SQL, they can't be reused in another context.

And, unfortunately (or maybe fortunately), ActiveRecord was built with
the expectation that there is a relational database that understands
SQL at the other side, so it isn't really a "possibility" to do what
you're looking for unless you start to build your own relational
database. Also, Merb is just a web framework, it doesn't have anything
like that.

If you write something that "looks like" active record, the view/form
methods woudn't change, but the association methods (has_one, has_many
and belongs_to) are something deeply rooted into active record and
SQL, they can't be reused in another context.

And, unfortunately (or maybe fortunately), ActiveRecord was built with
the expectation that there is a relational database that understands
SQL at the other side, so it isn't really a "possibility" to do what
you're looking for unless you start to build your own relational
database. Also, Merb is just a web framework, it doesn't have anything
like that.

A lot of activerecord generates sql fragments - it would be non
trivial to get around that.
There are a number of ActiveModel (which would abstract out some of
the relevant bits) efforts going on that may be of interest.

Fred

Frederick Cheung <frederick.cheung@gmail.com> writes:

There are a number of ActiveModel (which would abstract out some of
the relevant bits) efforts going on that may be of interest.

That's good to know, do you know any names/links/pointers for these
efforts?

Thanks -- Eric