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