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: Dave Howell on 7 Jun 2010 18:05 On Jun 6, 2010, at 15:55 , Phrogz wrote: > > I encourage you to give Sequel a long, hard investigation before > discounting it. Oh, believe me, Sequel has never been 'discounted.' Just my own digging had Sequel as one of the three top candidates on my list. On Jun 6, 2010, at 7:03 , Edward Middleton wrote: > > I am in no way advocating you do it this way but if you are going to > throw away all the advantage of using a good domain model[1] then you > may as well just pass data to your templating engine. Postgresql has a > driver ruby-pg[2], thats probably what you want. I've got a number of scripts already that drive data in and out of Postgres 'directly,' but I've been assuming that once I add a templating engine and web adapter, that they'll be much easier to use if I'm giving them Ruby objects that look like what ORMs make, rather than a big array or some such. 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. On Jun 5, 2010, at 14:46 , Walton Hoops wrote: > So assuming you already have a table named 'demos' in your database, you > can just run 'script/generate model demo' and TADA! It works. Except that it didn't. I tried that, but I just ended up a bit sad and rather puzzled. > Or if you > want, you can just create the demo.rb file in your app/models directory > and that will work too. Er, OK. But **how**? Everything I've found just assumes I'll use the magic script command to make it. Nothing tells me "here's how you'd build one by hand, if you were so crazy that you'd want to do it that way." > 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've thought so, too. But I just ended up with a whole lot of "Could not create table blahblahblah. Unrecognized data type UUID." messages in the file. I'd post it verbatim, but I'm afraid I've already wiped the test folder and de-installed Rails. On Jun 5, 2010, at 0:17 , John W Higgins wrote: > I'm surprised you mentioned Sequel in that list [of things with Rails-centric documentation] > because Sequel is very much > non-rails based and I've not seen much mention of rails in the docs at all ( > http://sequel.rubyforge.org/). I admit that the quick sample on the home > page does create a table but that is much more in the sense of having a > sample that is self-contained rather then forcing you to do anything at all > in terms of creating the schema within Sequel. I was probably overly broad in my characterization. I believe, actually, that I read through the Sequel documentation fairly early in my research, and ran across the "how to make a table in your database from within Sequel," did NOT find a "how to make Sequel construct an object FROM your table" as easily, and moved on to some of the other candidates in the list just because I was trying to learn a little bit about everything first. While creating a table in the DB from an object isn't intrinsic to Rails, it does reflect the object-centric (vs. database-centric) perspective that keeps coming between me and the information I really want to find. So: lots of votes for Sequel. I am installing the gem even as I write this. Thank you all, and for the sake of posterity, archiving, and others who might come along later wondering the same thing, I'll do a follow-up post with the results.
From: Walton Hoops on 7 Jun 2010 19:40 On 6/7/2010 4:05 PM, Dave Howell wrote: >> >> So assuming you already have a table named 'demos' in your database, you >> >> can just run 'script/generate model demo' and TADA! It works. >> >> >> > > Except that it didn't. I tried that, but I just ended up a bit sad and rather puzzled. > > > 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. > > > >> >> Or if you >> >> want, you can just create the demo.rb file in your app/models directory >> >> and that will work too. >> >> >> > > Er, OK. But **how**? Everything I've found just assumes I'll use the magic script command to make it. Nothing tells me "here's how you'd build one by hand, if you were so crazy that you'd want to do it that way." > > > 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. That said, all you need to put in that demo.rb file for the basic functionality is: class Demo < ActiveRecord::Base end Of course that assumes a few things, for example that you have a table named 'demos'. If you want to break that convention you'd have to look up how (in this case via :table_name function), but even using the magic scripts you'd have to look that up. >> >> 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've thought so, too. But I just ended up with a whole lot of "Could not create table blahblahblah. Unrecognized data type UUID." messages in the file. I'd post it verbatim, but I'm afraid I've already wiped the test folder and de-installed Rails. > > > > > That is the kind of error you get running a database migration. Again, you DO NOT need to run ANY migrations to use Rails. It sounds to me like you never really understood how Rails actually worked and that's at least half the problem. 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. If you do decide to give Rails another look I'm sure you'll find plenty of people willing to help on the Rails list.
From: Edward Middleton on 7 Jun 2010 21:59 On 06/08/2010 07:05 AM, Dave Howell wrote: > On Jun 6, 2010, at 7:03 , Edward Middleton wrote: >> >> I am in no way advocating you do it this way but if you are going to >> throw away all the advantage of using a good domain model[1] then you >> may as well just pass data to your templating engine. Postgresql has a >> driver ruby-pg[2], thats probably what you want. > > .. but I've been assuming that once I add a templating engine and web > adapter, that they'll be much easier to use if I'm giving them > Ruby objects that look like what ORMs make, rather than a big array > or some such. 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. > 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. Well it should make having an object model useful rather then a distraction. Edward
From: Dave Howell on 7 Jun 2010 22:02 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.
From: Dave Howell on 7 Jun 2010 22:15
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...} 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. On the other hand, I cannot imagine that I could possibly *over*estimate the advantages that a modern templating engine can give me. My baseline is Tango 3, which dates from 1996. Before that, I build a whole website with .idc/.htx file pairs in IIS, which was before Microsoft had invented Active Server Pages. http://www.thefreelibrary.com/EveryWare+Releases+the+Windows+beta+version+of+Tango%3B+EveryWare...-a018391130 God help us all if Haml, et al, can't do any better than that. |