Looking for ORM for 'legacy' database.
in [Ruby]
|
Prev: [ANN] Rainbows! 0.94.0 - one eight ate my homework!
Next: Unexpected length of £ (pound) character?
From: Edward Middleton on 7 Jun 2010 23:23 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. Edward 1. http://www.amazon.com/Patterns-Enterprise-Application-Architecture-Martin/dp/0321127420
From: Edward Middleton on 8 Jun 2010 09:06 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. Edward
From: Brian Candler on 8 Jun 2010 10:11 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 "id". 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 end 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 objects/rows. 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) Regards, Brian. -- Posted via http://www.ruby-forum.com/.
From: Brian Candler on 8 Jun 2010 10:22 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' end 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 ... PlaylistItem.create!( :pli_playlist_id => @playlist.plt_id, :pli_track_id => ... :pli_order => ... ) ... end -- Posted via http://www.ruby-forum.com/.
From: Brian Candler on 10 Jun 2010 04:56
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: http://ar.rubyonrails.org/ 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 :-) Regards, Brian. -- Posted via http://www.ruby-forum.com/. |