[Rails] Re: Generating SQL from model and not vice versa

[James Britt]

Lon Baker wrote:
> On Feb 28, 2005, at 1:54 PM, James wrote:
> 
>> OK, I see, and that's basically what I do now.  In fact, I have a case
>> where a client has a set of pages and a description of the behavior, but
>> no details on implementation (naturally).
> 
> 
> So the client handled the present step for you then.
> 
> When you say no details on implementation, what is missing? Is it 
> something that involves the interface or the model?

Sort of both, but really on the model end.  The client has an idea in 
mind, has worked out the pages and application flow (barring some 
assorted minor details).  But no work had been done to explicitly model 
what's going on in any formal way.  One has to bounce around the pages 
to see where different properties of assorted objects appear to piece 
things together.  So it's possible that as one is working backwards from 
the view that you discover, oh, yeah, this thing here needs a date 
attribute in order to make this page work.

> 
>> So, from looking at the the pages, having discussions, reading and
>> making notes, I've teased out a first set of likely objects for the 
>> model.
>>
>> To play this out in Rails, though, and evolve the application,  I need
>> to first create the database and tables before I can get to the models.
>>
>> As I go along, I'll perhaps see that a given attribute serves no
>> purpose, or (more likely) that a model is missing some essential 
>> property.
> 
> 
> That is part of the modeling step in my opinion.

Of course.  But you need to bounce out to a SQL tool to do it.

> 
>> Ordinarily (e.g., in a non-database-centric app), one would go to the
>> source files where the classes are defined and just add or edit the
>> accessors, and keep on coding and testing.  It's all just a Ruby coding
>> session.  But with Rails, one has to go open up some database admin tool
>> and/or muck with SQL to alter a model.
> 
> 
> One of many huge time savings in Rails happens right there. Instead of 
> editing code, adding setters/getters and confirming compatibility with 
> your persistence layer, you simply modify the persistence layer.

Same thing.  The assumption would be that the class attributes would 
automagically drive the persistence layer; you don't need to confirm 
compatibility.  The code is the authoritive description of the tables, 
as opposed to the tables defs being the authoritive description of the 
objects.  I don't see tying out field anes as any easier than tying out 
object attributes.

> 
>> I'm suggesting that this breaks the flow, and that it might be nicer if
>> one could work out the models as Ruby classes, without being concerned
>> with just how things are being persisted.
> 
> 
> With the persistence layer maintaining the database, tables, rows, 
> fields and naming conventions why duplicate the effort?

It's not duplication if you let the code drive the table defs.  And the 
main motivtion is mental, not manual, labor.

> 
> Is it only to avoid switching to a tool specially designed for such 
> tasks and doing it with a few clicks/

Few clicks?  Hardly.  Either way I have to type the table/class name, 
field/attribute names, data types, and associations.  No savings on 
typing either way, but one less conceptual shift if everything is driven 
by code.

Just a thought.


James