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.]
On Fri, Jun 4, 2010 at 2:29 AM, Dave Howell
> 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" (
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.
From: Walton Hoops on 5 Jun 2010 17:46
On 6/4/2010 3:29 AM, Dave Howell 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 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:
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" 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 then you
may as well just pass data to your templating engine. Postgresql has a
driver ruby-pg, thats probably what you want.
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
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