From: Edward Middleton on
On 06/08/2010 11:15 AM, Dave Howell wrote:
> On Jun 7, 2010, at 18:59 , Edward Middleton wrote:
>> I think you might be underestimating the difficult/complexity of faking
>> a domain model and overestimating the advantage gained from the various
>> template helper functions, as always YMMV.
> That's quite possible. Er, 'faking' a domain model? I'm not even sure
> what that means. {off to Wikipedia...}

The wikipedia page isn't particularly useful. Martin Fowlers web page is
better, i.e.

"An object model of the domain that incorporates both
behavior and data."

and there is a reasonable explanation in EAA[1].

> Ah. I don't think I'm trying to 'fake' that. I am putting in tremendous
> effort to ensure that the data and relationships in my database are as
> accurate and complete a model of how the information flows between the
> various departments and members of the corporation for whom I'm working,
> as possible. I certainly hope to have the Ruby components reflect that
> as well.

Well a domain model is pretty much that plus behavior but starting from
an object model and then mapping to a database.



From: Edward Middleton on
On 06/08/2010 08:39 PM, Richard Conroy wrote:
> On Mon, Jun 7, 2010 at 11:05 PM, Dave Howell
>> I still haven't figured out what, exactly, a Domain Model will do for me,
>> or even exactly what it is, but I'm not (deliberately? consciously?) trying
>> to throw those advantages away. Thanks for the links.
> Having model objects saves a LOT of coding. It gives you intuitive places
> to put validation. It integrates well into testing apis and makes the client
> side coding very tidy and natural. In addition you can get a lot of free
> features if you use an API like DM or AR (like SQL injection protection, or
> form helpers). Do not underestimate the saving in lines of code.

The problems occur when you go from a database schema to a domain model.
All the major ORM frameworks are built on the assumption you will
confirm the database to the domain model, not the other way round. i.e.
Object Relational Mapping not Relational Object Mapping ;)

Legacy database mapping is hard and not something you should do unless
really necessary. i.e. you don't control the database and so can't chose
a reasonable schema.


From: Brian Candler on
Dave Howell wrote:
> I actually used to have all my primary keys' names like 'product_id" in
> table 'products' in anticipation of using Rails with it one day, but I
> got tired of dealing with underscores, and stripped them out.

Aside: Rails (or ActiveRecord) expects that the primary key is called

Now, I've written applications which connect ActiveRecord to an existing
legacy database which doesn't respect Rails conventions, and they work
fine. For example, if I want a model class called Playlist then AR will
normally assume a table called "playlists" and a primary key of "id",
but these are easily overridden:

class Playlist < ActiveRecord::Base
self.table_name = 'venue_playlist'
self.primary_key = 'plt_id'

# Similarly for foreign key relations
has_many :playlist_items, :foreign_key => 'pli_playlist_id',
:order => 'pli_order', :dependent => :delete_all

I'm not 100% sure how well AR copes with a non-numeric primary key, but
I believe it's OK. Once you define the primary key explicitly, it no
longer tries to auto-assign it from a sequence, as far as I remember. So
you'll have to remember to set it explicitly when creating new

Where AR really falls down is when you have a composite primary key.
ISTR I came across some plugin for this, but I've never tried it.

> Because
> that's really at the heart of my search for an alternative to Rails.
> It's not actually a pre-existing database. I can still rewrite the
> schema as I see fit. I *could* start from scratch, build the database
> from within Rails, then import the data from its present true purgatory
> in a badly-designed Access database. However, too many of the defaults
> and assumptions in Rails are ones that I'm not willing to accept.

You really don't need to use migrations in Rails/AR. Trust me, I know.
The DBA team I work with won't let me have schema-level access to any
production database, so I have to provide them with SQL scripts which
they run manually to make schema changes.

Hence the app itself just reads the column definitions from the DB and
builds its object accessor methods from that; it cannot and does not
push out any schema modifications.

So I'd say:
* design and build your database how you want
* connect ActiveRecord to it as above
* watch it work
* if you really get stuck, then look at other ORMs (but I can't vouch
how well they will work with the rest of Rails, at least before Rails 3)


Posted via

From: Brian Candler on
Brian Candler wrote:
> class Playlist < ActiveRecord::Base
> self.table_name = 'venue_playlist'
> self.primary_key = 'plt_id'
> # Similarly for foreign key relations
> has_many :playlist_items, :foreign_key => 'pli_playlist_id',
> :order => 'pli_order', :dependent => :delete_all
> end

And for reference, here's the relation from the other side:

class PlaylistItem < ActiveRecord::Base
self.table_name = 'playlist_item'
self.primary_key = 'nonexistent'
belongs_to :playlist, :foreign_key=>'pli_playlist_id'

Notice that this particular table didn't really have a primary key as
such; each row was a unique tuple. Setting the primary_key to
'nonexistent' just proves that AR never attempted to use it.

At the controller side, all I needed to do was to set the attributes I
was interested in when creating the object.

def add_item
:pli_playlist_id => @playlist.plt_id,
:pli_track_id => ...
:pli_order => ...
Posted via

From: Brian Candler on
Dave Howell wrote:
> On Jun 8, 2010, at 7:11 , Brian Candler wrote:
>> Aside: Rails (or ActiveRecord) expects that the primary key is called
>> "id".
> Yea, but I'd already rejected that convention.
> create table Horses (
> horse_id primary-key-thing,
> ranch_id foreign-key-thing
> ...
> );

OK. You said you'd gotten tired of including the underscores, so I
wasn't clear want convention you were using instead.

> Oh, I never doubted it that it could be done. My problem was that the
> overwhelming percentage of available documentation assumes that I
> *won't* be doing it that way, so that I couldn't find the information I
> needed to make it work.

The AR documentation is pretty comprehensive. All I needed was to find
self.table_name = ...
self.primary_key = ...
and to look at the options provided by belongs_to/has_many.

Note that the AR documentation is available separately from the Rails
documentation here:

But anyway, if you've found something else you prefer, that's great. If
nothing else, it will likely to be much more lightweight than AR in
terms of startup time and memory usage.

> Um, but I hadn't planned on using Rails at all.

Sorry, I misinterpreted "in anticipation of using Rails with it one day"
as meaning that Rails was on your roadmap.

> I haven't gotten to actually using Haml yet, but it took me about 30
> seconds to fall in love with it. Barring catastrophic incompatibilities
> with Sequel &/or Ramaze (which seems highly improbable), I'm done
> evaluating, and have finally moved on to developing.

If you love it at first glance, you'll love it completely. I've done
projects with Sinatra+HAML as well as Rails+HAML. Hopefully I'll never
see another ERB template :-)


Posted via