Hello,
which is the best ORM for ruby?
and, is ORM really good on database handling?
Thanks.
I’ve been writing Ruby for three days now. DataMapper seems very good.
There are several benefits to ORMs; not the least of which is being able
to change the schema in your datastore without breaking all the client
code that accesses it.
Sam
On Wed, Nov 10, 2010 at 7:43 PM, zuerrong [email protected] wrote:
ActiveRecord, it is the default for Rails, and thus has a huge community
behind it. That counts for a lot, it means problems get found and fixed,
it
means people write subsidiary gems and plugins around it to add in
functionality for all sorts of things. It means any Rails book you go
through will teach you about it (ie the canonical AWDWR) it means there
are
really good guides at guides.rubyonrails.org (DataMapper has pretty
decent
guides too, and since it implements a lot of the ActiveRecord api, it is
pretty intuitive after you know AR).
It’s downside is that it is cumbersome using it outside of Rails.
On Thu, Nov 11, 2010 at 1:43 AM, zuerrong [email protected] wrote:
Hello,
which is the best ORM for ruby?
and, is ORM really good on database handling?
It all depends on what you want exactly. A Database ORM is an
abstraction of
a database, that inherently introduces compromises in how you work with
it.
The Ruby ORMs are quite famous - ActiveRecord made a huge case for ORMs
all
on its own. DataMapper is an excellent purist ORM. Also in Ruby you
should
consider the Sequel library, which includes an ORM layer (not as
abstracted
as either AR or DM, but that may be a really good compromise when
dealing
with legacy schema).
As a rule, I think the Sequel library may be unfairly overlooked in the
‘good ways to deal with databases category’.
There are genuinely good reasons for using ORMs in many cases, but
usually
the reason to use an ORM is to hide the nuisance of SQL. This means that
ORMs can often be used in situations that they really shouldn’t. I think
Sequel goes a huge way towards making SQL a lot easier to use in a
program,
and therefore ORM layers can be introduced on their merits.
That said, I haven’t used Sequel in anger, favouring DataMapper in my
Ruby
programs.
On Thu, Nov 11, 2010 at 04:31:28PM +0900, Josh C. wrote:
It’s downside is that it is cumbersome using it outside of Rails.
Another downside is that almost every tutorial, howto, or book that
gives
you a decent bit of help getting familiar with it assumes that you are
using it with Rails, which makes it kind of a pain in the butt to learn
to use effectively without rails.
Sam D. wrote in post #960638:
There are several benefits to ORMs; not the least of which is being able
to change the schema in your datastore without breaking all the client
code that accesses it.
This is what worries me about the descent of human kind into the cess
pit of ORMs.
Sam I’m sure you’re a decent person but it’s actually the opposite.
Databases are supposed to be designed with external schemas ie you never
program to a base table…ever! You program to views, and then you can
change the physical database to your heart’s content, even splitting
across nodes. Facades weren’t invented by the Gang of Four, they’ve been
a part of computer science for half a century.
Databases have a wealth of logic, elegance and functionality. Slapping
them in the crude harness of ORMs is a most unfortunate and regressive
trend.
Databases are supposed to be designed with external schemas ie you never
program to a base table…ever! You program to views, and then you can
change the physical database to your heart’s content, even splitting
across nodes.
Wow, there is a lot for you to learn yet… A good start would be
limitations
of views.
Regards,
Rimantas
On Fri, Nov 12, 2010 at 5:47 PM, Mike S. [email protected]
wrote:
Databases have a wealth of logic, elegance and functionality. Slapping
them in the crude harness of ORMs is a most unfortunate and regressive
trend.
Why?
–
Phillip G.
Though the folk I have met,
(Ah, how soon!) they forget
When I’ve moved on to some other place,
There may be one or two,
When I’ve played and passed through,
Who’ll remember my song or my face.
On Nov 12, 2010, at 6:18 PM, Phillip G. wrote:
Databases have a wealth of logic, elegance and functionality. Slapping
them in the crude harness of ORMs is a most unfortunate and regressive
trend.Why?
Why not?
An oldie, but a goodie 
“The Vietnam of Computer Science”
http://blogs.tedneward.com/2006/06/26/The+Vietnam+Of+Computer+Science.aspx
As Toon Koppelaars would say:
“Do not build applications that enable you to switch your DBMS, instead,
build applications that enable you to switch the ‘du-jour’ technology”
[health warning: do not follow these links if you are easily offended]
:))
http://web.inter.nl.net/users/T.Koppelaars/
http://web.inter.NL.net/users/T.Koppelaars/Building_Robust_Applications.doc
On Nov 12, 2010, at 9:42 PM, Rimantas L. wrote:
Wow, there is a lot for you to learn yet… A good start would be limitations
of views.
Another good start would be to understand SQL :))
“Double-thinking in SQL”
Petite A. wrote in post #961092:
On Nov 12, 2010, at 6:18 PM, Phillip G. wrote:
“The Vietnam of Computer Science”
Wonderful! I no longer feel alone in the World.
Join us, all you other sceptics!!! Let the bright light of goodness
overcome the dark evil of ORMs.
Make them shrivel and die!!!
On 11/12/2010 12:56 PM, Petite A. wrote:
http://blogs.tedneward.com/2006/06/26/The+Vietnam+Of+Computer+Science.aspx
Solution #5 seems to be pretty much nailed by Sequel (the gem), IMHO.
On Sat, Nov 13, 2010 at 05:56:19AM +0900, Petite A. wrote:
On Nov 12, 2010, at 6:18 PM, Phillip G. wrote:
[health warning: do not follow these links if you are easily offended] :))
That’s an important warning, given this link to a particularly ugly and
problematic file format:
http://web.inter.NL.net/users/T.Koppelaars/Building_Robust_Applications.doc
It’s the Web, folks. Try using (hyper)text, for crying out loud.
On Fri, Nov 12, 2010 at 9:56 PM, Petite A.
[email protected] wrote:
On Nov 12, 2010, at 6:18 PM, Phillip G. wrote:
Databases have a wealth of logic, elegance and functionality. Slapping
them in the crude harness of ORMs is a most unfortunate and regressive
trend.Why?
Why not?
It’s impolite to answer a question with another question. 
An oldie, but a goodie
“The Vietnam of Computer Science”
http://blogs.tedneward.com/2006/06/26/The+Vietnam+Of+Computer+Science.aspx
So, the very first argument against ORM is… turf wars. That’s not a
problem any technology can solve, since it is an organizational issue.
And all other arguments are pretty much balanced out by the simple
fact that encapsulating a database schema in a way that fits naturally
with the language used (so, objects for object-oriented languages)
improves productivity, and doesn’t lead to overhead by having to
switch from, say, C# to SQL every time.
And of course the impact of any given tool, technology, methodology
has to be evaluated before you invest in it (that’s where the Vietnam
War analogy breaks down, and breaks down hard). But that’s where ORM
can be a benefit: The developers don’t have to care about the
database stack, since they don’t have to deal with it. The ORM library
takes care of talking to databases.
In short: no technology is inherently evil or bad. It’s either used
appropriately, or not.
“Do not build applications that enable you to switch your DBMS, instead, build
applications that enable you to switch the ‘du-jour’ technology”
Dear Lord. Yes, build your tools in such a way that you are not
dependent on any single piece of technology. That’s easier in some
cases (an RDBMS can be exchanged relatively easily), and much more
difficult in other cases (changing from .NET to Java will require a
rewrite of the code). Not to mention that ORM can provide the
necessary abstractions to be able to switch from, say, from SQL to
NoSQL databases, so you aren’t stuck in the “technology du jour”.
–
Phillip G.
Though the folk I have met,
(Ah, how soon!) they forget
When I’ve moved on to some other place,
There may be one or two,
When I’ve played and passed through,
Who’ll remember my song or my face.
Petite A. wrote:
On Nov 12, 2010, at 6:18 PM, Phillip G. wrote:
Databases have a wealth of logic, elegance and functionality. Slapping
them in the crude harness of ORMs is a most unfortunate and regressive
trend.
“The Vietnam of Computer Science”
http://blogs.tedneward.com/2006/06/26/The+Vietnam+Of+Computer+Science.aspx
A well-written and often-quoted argument, but which is still lacking.
Ted
lists 6 possible balancing-points between objects and relations, but
fails
in thinking that these six exhaust the possibilities.
The O-R impedance problem is caused by them both being
attribute-oriented,
but using different principles for determining which things are
attributes
and which things are entities/objects.
Fact-oriented modeling (or semantic modeling, as I like to call it) is
attribute-free. The decisions about attributes vs entities/objects is
made
mechanistically, which produces a good relational model and a good
object
model which always remain in perfect lock-step, allows the possibility
of
automatic data migration, and has many other advantages, including
natural-
language modeling.
My “activefacts” gem provides an implementation of the Constellation
Query
Language, a semantic modeling language. Generators for existing Ruby
O/RMs
are still under development, though an early stage DataMapper generator
is
there. I plan to expand ActiveFacts to provide a new O/RM solution which
is
more in keeping with the fact-oriented approach, but that’s also still
in
development.
I’m not of the view that it’s a good thing to try to shoe-horn the
relational
calculus into the Ruby syntax, as AREL, Sequel and DataMapper attempt.
While
it’s cute that the Ruby syntax makes it possible, I don’t think this
solves
the big problem(s). Good language integration is always a good thing,
but I
have a different approach to it.
Anyhow, if you’re interested, you can “gem install activefacts” and find
more
details at http://dataconstellation.com/ActiveFacts.
Clifford H., Data Constellation, http://dataconstellation.com
Agile Information Management and Design.
On Sat, Nov 13, 2010 at 10:54 AM, Mike S. [email protected]
wrote:
My problem is the mismatch.
Objects have data that relates to what they are doing and can be
configured to suit their needs.The database approach views data as having an innate structure created
by many different stakeholders, use cases, and therefore many different
potential objects.
In other words: Databases contain data that relates to what the DBs
are doing, and that can be configured to their needs.
Essentially, the data that you store in a database, any database, has
to be massaged such that you can store it in the first place. AKA
normalization.
A language like SQL gives you a neat interface between the two worlds.
No, it doesn’t. SQL’s syntax is unlike any programming language I
know. Pure SQL contains no looping constructs, for example. It can
only retrieve and store data.
It is trivial to adjust an SQL call wrapper even if you need to. Any
minor extra burden on connecting from your Ruby program is more than
compensated by the more sophisticated (more precise) representations of
the data and the wealth of other database tools and services (stored
procedures, triggers etc) made available to you.
In how far is SQL’s representation of data “more sophisticated”? In
the end, the rows returned by an SQL query are nothing but an Array
(maybe a Hash with the SQL query as a key in Ruby parlance).
Since Triggers operate on the SQL statements, which the programming
language ↔ SQL DB interface has to use (no matter if it is shelled
out to the command line, uses ORM, or JDBC), you don’t lose the any
capabilities your SQL DBMS offers you, since those operate on the SQL
statements (they have to, since you don’t have to interact with a DB
with its vendor-supplied driver).
However, the abstraction offered by, say, ORM, allows the programmer
not to have to care about the underlying database, so he doesn’t
have to care about the SQL used. Which, considering the ugliness of
SQL, is no small blessing.
(Also as dog-collar wearing , fully ordained, anti-ORM preacher, it is a
matter of faith - I was just brought up to believe in these things. I
guess I’ll never change)
So, you aren’t arguing, you are preaching. I leave the credibility of
your arguments as an exercise to the reader.
–
Phillip G.
Though the folk I have met,
(Ah, how soon!) they forget
When I’ve moved on to some other place,
There may be one or two,
When I’ve played and passed through,
Who’ll remember my song or my face.
On Nov 13, 2010, at 2:35 PM, Phillip G. wrote:
SQL’s syntax is unlike any programming language I
know.
Broaden your horizon!
Pure SQL contains no looping constructs, for example.
Indeed, it’s declarative and set based.
It can only retrieve and store data.
“What Have the Romans Ever Done For Us?”?
– Monty Python, Life of Brian
http://www.epicure.demon.co.uk/whattheromans.html
At the risk of repeating oneself:
“Double-thinking in SQL”
http://explainextended.com/2009/07/12/double-thinking-in-sql/
My problem is the mismatch.
Objects have data that relates to what they are doing and can be
configured to suit their needs.
The database approach views data as having an innate structure created
by many different stakeholders, use cases, and therefore many different
potential objects.
A language like SQL gives you a neat interface between the two worlds.
It is trivial to adjust an SQL call wrapper even if you need to. Any
minor extra burden on connecting from your Ruby program is more than
compensated by the more sophisticated (more precise) representations of
the data and the wealth of other database tools and services (stored
procedures, triggers etc) made available to you.
(Also as dog-collar wearing , fully ordained, anti-ORM preacher, it is a
matter of faith - I was just brought up to believe in these things. I
guess I’ll never change)
On Sat, Nov 13, 2010 at 5:35 AM, Phillip G.
[email protected] wrote:
No, it doesn’t. SQL’s syntax is unlike any programming language I
know. Pure SQL contains no looping constructs, for example.
This is probably based on some version of SQL prior to SQL-99; from
SQL-99 on, SQL has had a looping construct in the form of recursive
common table expressions.
It can only retrieve and store data.
Well, it can only retrieve, store, and do quite a bit of processing with
data.
On Sat, Nov 13, 2010 at 3:29 PM, Petite A.
[email protected] wrote:
On Nov 13, 2010, at 2:35 PM, Phillip G. wrote:
SQL’s syntax is unlike any programming language I
know.Broaden your horizon!
No, thanks. If there’s big iron to be programmed for, I get a
specialist, and neither FORTRAN nor COBOL matter for new code.
(I know, Mathlab & co are declarative, too, but these things are tools.)
Pure SQL contains no looping constructs, for example.
Indeed, it’s declarative and set based.
It can only retrieve and store data.
“What Have the Romans Ever Done For Us?”?
– Monty Python, Life of Brian
That’s one broken analogy. Specialized databases make datastorage and
-retrieval much easier than the good ol’ text file, but that’s all
they are good for: Datastorage and -retrieval. We aren’t talking about
a technologically more advanced culture subsuming and enslaving its
neighbors.
–
Phillip G.
Though the folk I have met,
(Ah, how soon!) they forget
When I’ve moved on to some other place,
There may be one or two,
When I’ve played and passed through,
Who’ll remember my song or my face.