Re: Looking for ORM for 'legacy' database.

On Jun 7, 2010, at 16:40 , Walton Hoops wrote:

>> How did it not work?  I guarantee something happened.  My guess would
>> that you didn't set the schema_search_path correctly in your
>> 'config/database.yml' file so it couldn't find the table, but without an
>> error message that is just a guess based on the kind of mistake I would
>> make. 

I explained this a bit more in my original message: 
> 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. 

>> You're probably right, everything assumes you will learn by following
>> the tutorials or books, which believe it or not do show you how to edit those files manually.

It seemed likely that the information existed. However, I am NOT sure that it existed somewhere other than in the core documentation. And the core documentation was quite incomprehensible. Like 95% of all the RDoc/ri information on my computer, it's organized for reference: to give you the details about a particular part of the library or module. If you don't know *which* command you want in the first place, or if you're trying to do something that isn't a function of a single command, then you can't just 'find' it in the reference documents. 

In order for me to figure it out from the primary documentation, I would first have to have a good solid understanding of how Rails works, and where it puts things. I would have to work through all the tutorials and build a bunch of little sample websites. Then I might be able to figure out how to do what I wanted to do, and whether or not it would do *everything* I required, or only *some* of it. 

Or, I could ask people who already had that knowledge, and save myself many hours of work. {smile}


>> That is the kind of error you get running a database migration. Again,
> you DO NOT need to run ANY migrations to use Rails.

To use it? No. But I didn't need to 'use' it. I needed to evaluate it. To evaluate it, I needed to work through a tutorial or two, but with MY data. And I could not find *any* information designed to introduce me to Rails that did not take for granted that there was *no* pre-existing data, because that's very much how Rails expects you to work: you build the database from Rails. There were a few bits of info here and there that hinted at how to build a migration file from an existing database, but because Rails (or ActiveRecord, or whatever component was in charge of this part) failed to handle my UUID primary keys, it didn't work. 

> It sounds to me like you never really understood how Rails actually
> worked and that's at least half the problem. 

No, actually, I'm pretty sure I understood all too well how Rails works. 

A gentleman named William Pietri commented in a blog post by Derek Sievers "Treating the database as the main focus, rather than an implementation detail is, from the Rails perspective, the wrong approach. And Rails is very opinionated software; it does its thing well, but if you want it to do something else, it's not a good match." 

This was exactly what I had already concluded. As long as I was doing things "the Rails way" stuff happened almost magically. As soon as I veered off the path, I was fighting for every inch of progress.

{search search search}

Aha! Something new! Somebody actually has a blog entry for "Ruby on Rails: UUID as your ActiveRecord primary key"

http://ariejan.net/2008/08/12/ruby-on-rails-uuid-as-your-activerecord-primary-key/

"[rake db:schema:dump] does not look at the id column in your database, but instead adds the default primary key definition from the ActiveRecord adapter. The solution is to disable the id column and create a primary key column named uuid instead."

As per a number of other Rubyist's recommendations, I've installed Sequel. Sequel *does* look at my database and automatically respects what the db defines as the primary key. (It isn't clever enough to automatically adopt the pre-existing *foreign* key constraints, but I'm willing to live with that.)

Let me repeat at this point: I am NOT here to try to slam Rails, or ActiveRecord, or such. I'm sure they're very popular for very good reasons. People have made some pretty amazing sites in preposterously short time spans with them. I just felt that my particular situation was probably not one of them.

>  That said there is nothing
> wrong with just writing a data access layer over your database (or using
> Sequel/ActiveRecord/GenericORMHere) and providing it to a web app
> written in Sinatra or something similar.  In fact, given that you have a
> pre-existing database that likely violates many of Rails conventions
> that may be the best way to go.

Interesting turn of phrase. "Violates many of Rails conventions." Indeed. "Fails to subscribe to Rails' orthodoxy" might be another way to phrase it. 

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. 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. 

It's hard (for me) to tell what one really can do, or do easily, in ActiveRecord because there's so many posts on the web that are out of date. Is support for foreign keys built into it yet, or is it still an optional module? I'm not sure. But I'm sure that I don't want an ORM that *can* present a complete model of my data, I want one that *wants* to.