Driving Rails from disk instead of SQL


#1

Rails mailing list
removed_email_address@domain.invalid
http://lists.rubyonrails.org/mailman/listinfo/rails


#2

Rails mailing list
removed_email_address@domain.invalid
http://lists.rubyonrails.org/mailman/listinfo/rails


#3

On May 25, 2006, at 10:05 AM, Michael T. Richter wrote:

Ideally what I’d like to be able to do is have my Rails app browse
the directory tree directly and generate the forms, etc. on the
fly, filling it in with ID3 information as it does so. The problem
is that I can’t, for the life of me, figure out how to make Rails
use the file system as, in effect, a hierarchical database full of
BLOBs. I’m sure I have to write some kind of front-end for
ActiveRecord or something that does the trick, but I really don’t
even know where to begin with this. I’ve done a lot of digging
around at various Ruby- and Rails-oriented sites and can’t quite
see anything helpful.

This is pretty easily done as it turns out. What you are trying to do
is write a Rails application without using ActiveRecord (I’ve seen a
few discussions about this but I don’t have any links). Not using
ActiveRecord is done simply by not extending ActiveRecord::Base (or
whatever, that class name is from memory). There has been a recent
discussion on where to put the model in that case – I put mine under
the lib directory, but vendor will work too.

By not using ActiveRecord you are basically writing straight Ruby
code to do what you need, so you’ll have to pay attention to
transactional issues yourself. Unless you are happy using Webrick or
Mongrel don’t try to hang onto information across requests unless it
is serializable and included in the session object. If you cannot use
the session object (as I cannot) then you have to use Webrick or
Mongrel in production (and I’m happy to do so). Unit testing is going
to be a pain (unless this was fixed in 1.1 you’ll have to create a
dummy db to use Rails’ unit test capabilities).

Another useful trick is to use Rails’ capability to re-load changed
classes. The mechanism has apparently changed in 1.1 but in 1.0 it
was done by using ‘require_dependency’ rather than ‘require’.

This all leaves aside any discussion of whether this is a good idea
– it certainly has been for me, but…

Cheers,
Bob


Bob H. – blogs at <http://www.recursive.ca/
hutch/>
Recursive Design Inc. – http://www.recursive.ca/
Raconteur – http://www.raconteur.info/
xampl for Ruby – http://rubyforge.org/projects/xampl/


#4

Well, the “business logic” does belong with the model code, but the
directory name under which the model code is stored is completely
arbitrary. To illustrate what I mean, if rails was written in German
for German users, would the model directory still have to be called
model? Shouldn’t it be called modell? So what the name of the
directory is doesn’t matter… just do what’s most convenient, just so
long as you keep it all together.
-N


#5

On 5/25/06, Bob H. removed_email_address@domain.invalid wrote:

Not using
ActiveRecord is done simply by not extending ActiveRecord::Base (or
whatever, that class name is from memory). There has been a recent
discussion on where to put the model in that case – I put mine under
the lib directory, but vendor will work too.

IMHO your business logic belongs in the model directory, how you do
persistence is irrelevant, while lib is for ‘utility’ code specific to
your project, e.g. an ID3 tag reader or whatever.

If your ID3 reader is substantial/interesting/mature enough to ship as
a gem, it belongs in vendor.