ruby ORM

Z

zuerrong

Hello,

which is the best ORM for ruby?
and, is ORM really good on database handling?

Thanks.

--=20
Kind regards,
=C2=A0 =C2=A0 =C2=A0Zuer (=E7=A5=96=E5=84=BF)
 
S

Sam Duncan

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
 
R

Richard Conroy

[Note: parts of this message were removed to make it a legal post.]

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

Josh Cheek

Hello,

which is the best ORM for ruby?
and, is ORM really good on database handling?

Thanks.
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 decen=
t
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.
 
M

Mike Stephens

Sam Duncan 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.
 
P

Phillip Gawlowski

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 Gawlowski

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

Rimantas Liubertas

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=E2=80=A6 A good start would be lim=
itations
of views.


Regards,
Rimantas
 
P

Petite Abeille


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"=20=


[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.do=
c
 
M

Mike Stephens

Petite Abeille wrote in post #961092:
On Nov 12, 2010, at 6:18 PM, Phillip Gawlowski 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!!!
 
C

Clifford Heath

Petite said:

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 Heath, Data Constellation, http://dataconstellation.com
Agile Information Management and Design.
 
P

Phillip Gawlowski


It's impolite to answer a question with another question. ;)

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 Gawlowski

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

Mike Stephens

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)
 
P

Phillip Gawlowski

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 =A0more sophisticated (more precise) representations o= f
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.

--=20
Phillip Gawlowski

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

Petite Abeille

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/
 
P

Phillip Gawlowski

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.)
Indeed, it's declarative and set based.


"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 Gawlowski

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

Christopher Dicely

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

Mike Stephens

Phillip Gawlowski wrote in post #961199:
that's all they are good for: Datastorage and -retrieval.

I needed to process some data for automated test scripts this morning. I
switched on my rigorously locked down corporate laptop which has
absolutely no chance of getting Ruby on it. So I try VBA and
blow-me-down they've locked out ADOX. No chance of getting that sorted
this side of Xmas so I was forced to turn to good old Access. An hour or
two after that everything was sorted and I didn't even need to write a
line of code - not even edit raw SQL.

Cast off that ORM straightjacket and explore the bright lights of the
database world. You'll have some fun!
 
P

Phillip Gawlowski

Phillip Gawlowski wrote in post #961199:

I needed to process some data for automated test scripts this morning. I
switched on my rigorously locked down corporate laptop which has
absolutely no chance of getting Ruby on it. So I try VBA and
blow-me-down they've locked out ADOX. No chance of getting that sorted
this side of Xmas so I was forced to turn to good old Access. An hour or
two after that everything was sorted and I didn't even need to write a
line of code - not even edit raw SQL.

Since Access contains VBA since Access 95 (before that, it was Access
Basic in 1.x and 2.x), and has only an SQL-ish syntax (the JET engine
itself isn't compliant to any SQL standard), I don't have to point out
the irony in the above paragraph.

Further, you might want to look up Data Access Objects (It's a flavor
of ORM) and ActiveX Data Objects (another flavor of ORM), which both
provide a layer of abstraction to decouple code from the underlying
database.

In an analogy: Since Access includes a report designer, we can cast
off the shackles of the Crystal Reports prison. Nevermind the
additional features Crystal Reports offers.
Cast off that ORM straightjacket and explore the bright lights of the
database world. You'll have some fun!

You didn't understand a single point I made, did you?

--=20
Phillip Gawlowski

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.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,744
Messages
2,569,483
Members
44,903
Latest member
orderPeak8CBDGummies

Latest Threads

Top