Re: Looking for ORM for 'legacy' database.

On 6/4/2010 3:29 AM, Dave Howell wrote:
> [snip]...[/snip]
>
> "Migrations" really had me mystified when I started trying to figure out Rails. The idea that I would ever consider letting the middleware have any kind of write access to the database schema seemed so improbable that I spent rather a lot of time looking for the 'other' tutorial, the one where you start with the data and work your way forward to the web site, rather than starting in the middle and working out in both directions. 
>
> I eventually figured out that Rails just doesn't work that way. Clearly, the paradigm that it uses is very effective for a lot of people. That's a fine thing; I'm not here to try to convince people that it's doing stuff the 'wrong way.' I just need to find something that supports a more data-centric (and database-centric) approach. 
>   

But it doesn't.  I'm surprised no one has mentioned it yet, but there is
nothing about Rails that forces you to use migrations.  Here's a quick
demo of ActiveRecord (the Rails ORM) without migrations:
http://gist.github.com/427016

So assuming you already have a table named 'demos' in your database, you
can just run 'script/generate model demo' and TADA! It works.  Or if you
want, you can just create the demo.rb file in your app/models directory
and that will work too.

Now it's true, if you use some the of the generators (such as the model
generator above), they will generate some migrations, but you can simply
*GASP* not run them.  Your code will still work fine.

> [snip]...[/snip] It's brand new, and I'm leveraging Postgres's feature set hard in order to protect the integrity of the data. Composite unique keys, foreign keys, and two different custom datatypes are part of the schema, for example.
>   
Foreign keys are easy, just look up how to use the associations such as
:has_one and :has_many.  Composite keys are a little more difficult, but
there is a plugin for that (http://compositekeys.rubyforge.org/).  The
custom data-types are a sticky point.  I don't have a Postgre
installation handy, and a quick Google didn't turn up anything in the
way of problems or solutions, so I don't know what may or may not work. 
I'd start by using the :class and :methods functions on those columns to
see what you get.  I may give it a try later to see what I can come up with.

> ActiveRecord did turn out to have a command available to build its migration file (I think that's what it was) FROM the schema, rather than vice versa. Unfortunately, it only managed to extract about 20% of the tables, because I'm using UUIDs for the primary keys, not sequences or integers, and it didn't know what to do with a UUID. I have no doubt that there is some place, somewhere, where I could define a new database type, but a couple of hours digging and fiddling with various files didn't lead me to the solution. 
>   

Again, schema.rb (which is what your trying to generate) is COMPLETELY
unnecessary.  It's only useful if you want to manage your schema with
Rails. As for UUIDs as PKs, you'll notice in the example above that I
used strings as a PK with no difficulty.  UUIDs should work the same way.

> I did get the distinct impression that, while it was almost certainly possible, it probably wouldn't ever be smooth. I decided it made more sense to try to find an ORM that was more comfortable with the idea it could only reflect the database's schema, rather than trying to make the DB schema conform to Ruby objects. 
>
> So far, I've found DataMapper, Friendly, M4DBI, Ohm, and Sequel as possible alternative ORMs, but all the documentation for them is heavy with terminology and jargon from Rails, and usually brags about how I can make tables appear in my database magically from my Ruby objects. Which ORMs are better for connecting to my Postgres databases in a way that will best take advantage of, or at least not get in fights with, the constraints enforced by Postgres itself?
>   
The only one on this list that I've used with Postgre is sequel, which
may be what your looking for.  It is certainly less opinionated than
ActiveRecord.  The one issue that I ran into with sequel is that it has
a very poor understanding of schema_search_path so working with multiple
schemas can be annoying.

Hope this helps.