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: John W Higgins on 5 Jun 2010 03:17 [Note: parts of this message were removed to make it a legal post.] Evening Dave, On Fri, Jun 4, 2010 at 2:29 AM, Dave Howell <groups.2009a(a)grandfenwick.net>wrote: > 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 I'm surprised you mentioned Sequel in that list 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. You will note that the create table call is totally non-related to later accessing the table and has nothing to do with ruby objects - it's simple a method that you can use to create a table - nothing more nothing less. I think you'll find Sequel very much to your liking with respect to the fact that it's heavily based on "datasets" ( http://sequel.rubyforge.org/rdoc/files/doc/dataset_basics_rdoc.html) which sounds like a concept that you would be rather happy with.... I would very much steer you towards website docs to see if Sequel might just meet your needs. If you had specific questions once you had a look - the Sequel mailing list/google group (http://groups.google.com/group/sequel-talk) is an excellent way to get help. Jeremy is exceptionally responsive to issues and questions and very much goes the extra mile to help folks out. Specifically with respect to UUIDs or your custom datatypes - I'm sure you would find an answer either from the docs or from Jeremy via the mailing list that will satisfy you. I'm also thinking that it would be very easy to setup a small test to see how Sequel handled your "interesting" fields. John
From: Walton Hoops on 5 Jun 2010 17:46 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.
From: Edward Middleton on 6 Jun 2010 10:03 On 06/05/2010 09:40 AM, Dave Howell wrote: > > On Jun 4, 2010, at 7:25 , Edward Middleton wrote: > >> On 06/04/2010 06:29 PM, Dave Howell wrote: >>> Thanks for reading to the end of a pretty long message, and thanks >>> even more to those of you who help me figure out where to look for the >>> answers. :) >> >> Get a copy of "Patterns of Enterprise Application Architecture"[1] read >> and grok that first. If you are just confirming your model to your >> database you don't need objects. They will just be a distraction ;) > > Well, I'm going to need *something* to hand over to the templating engine in order to build web pages. 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. Edward 1. http://martinfowler.com/eaaCatalog/domainModel.html 2. http://bitbucket.org/ged/ruby-pg/wiki/Home
From: Mike Stephens on 6 Jun 2010 16:47 Dave Howell wrote: > For my work, the data is the supreme treasure, and the database engine is the > god-emperor. > You're spot on, Dave. ORMs are the Devil's spawn. Stay well clear. -- Posted via http://www.ruby-forum.com/.
From: Phrogz on 6 Jun 2010 18:50
On Jun 4, 3:29 am, Dave Howell <groups.20...(a)grandfenwick.net> wrote: > "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 [...] You can use a migration that speaks raw, engine-specific SQL to the DB, and still have the benefit of migrating up and down. > I've been looking at various non-Rails options, and it looks like, to a certain degree, > it turns into a snap-your-own-together situation, where I get to pick a framework [...] > an adapter [...] a templating engine [...], and an ORM. I personally recommend Sinatra, Haml, and Sequel as the foundation, with Thin and Nginx as deployment details. (To lend some credence to my recommendation, I've been doing web development since 1994, professionally since 1996, and used beyond the level of experimentation: VBScript ASP, JScript ASP, ASP.NET, Rails, Ramaze, Sinatra with hand-rolled ORMs, ActiveRecord and Sequel, deployed on IIS, Apache, Webrick, Mongrel, Thin, backed by MSSQL, SQLite, and PostgreSQL.) > 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. Reflecting convention-over-configuration thinking, Sequel requires the least amount of work (no configuration) when your design matches what it expects, but you have the ability to customize table names, PKs, FK columns, etc. to match your setup. I've not yet had a schema that I couldn't map nicely to reasonable objects, though I'm often designing with the ORM in mind instead of mapping a completely legacy schema. Sequel's maintainer (Jeremy Evans) seems a big fan of PostgreSQL, is quite knowledgeable on deep DB concetps, and (both at the moment and for years now) has been incredibly responsive and helpful. I find Sequel's documentation excellent, and yet that seems to be considered its weakest point at the moment (and undergoing additional and substantial improvement). The only area that I've personally felt the documentation was 'deficient' is that the introductory documentation makes it appear that Datasets are the primary intended way of working with data, with Models and ORM an afterthought. I call this 'deficient' because it is not the case: Sequel's Models are fully supported, first-class, and powerful. I encourage you to give Sequel a long, hard investigation before discounting it. |