Ruby ORM

ruby-talk
21

On the contrary, ORMs let people utilize this wealth of domain knowledge in
SQL databases without having to touch the abysmal puddle of vomit that is
SQL, and using familiar object interfaces through metalinguistic
abstraction.

ORMs rock, and they're a stepping stone towards a future where distributed
"NoSQL" data stores will be a satisfactory replacement for the dinosaurs
that are SQL databases.

That said, I still use MySQL as our only database.

···

On Fri, Nov 12, 2010 at 9:47 AM, Mike Stephens <rubfor@recitel.net> 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.

--
Tony Arcieri
Medioh! A Kudelski Brand

22

Rimantas Liubertas wrote in post #965923:
And

win32ole
won't fire, because I am on OS X.

I think we all understand that if you're on different platforms you have
to translate what I said. It would be quite pointless for me to start
listing all software on all platforms. Normally people know this.

···

--
Posted via http://www.ruby-forum.com/\.

23

Ryan Davis wrote in post #966039:

What does this have to do with the "ORM's Don't Do It" thread?

Don't thread hijack. Man up and hit "new message".

This is to do with a current trend - domain specific languages.

You can try and write applications in a single language. ORMs try and
make relational databases look like Ruby.

The alternate view is to say an application should use a set of
different languages each optimal for the task at hand.

So for database tasks, which include manipulation of large sets, sharing
of data, replication etc, you should be happy to use SQL or other
database languages and not try and shoe horn them into Ruby, at least
without some very clear justification.

Typically Ruby applications accept regular expressions, HTML, CSS, Rails
and number of other DSLs -why have a hang up about SQL?

I am extending that principle to say other applications are just as
valid candidates for you to use in your solutions.

If a problem looks like a spreadsheet ie has one or a series of two
dimensional
arrays with positional significance, you should consider whether a
spreadsheet application might more naturally express your algoritm.

···

--
Posted via http://www.ruby-forum.com/\.

24

Bogus arguments by MS devs were used to support the "ORMs Don't Do It" ?

... but everything is connected.

Thanks

Michal

···

On 3 December 2010 22:13, Ryan Davis <ryand-ruby@zenspider.com> wrote:

On Dec 3, 2010, at 00:49 , Mike Stephens wrote:

I was thinking about this last night and it's part of a belief I have
that you reuse powerful facilities available to you rather than imitate
them or bodge them into Ruby.

What does this have to do with the "ORM's Don't Do It" thread?

25

Why not?

An oldie, but a goodie :slight_smile:

"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 6:18 PM, Phillip Gawlowski 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?

26

Another good start would be to understand SQL :))

"Double-thinking in SQL"

···

On Nov 12, 2010, at 9:42 PM, Rimantas Liubertas wrote:

Wow, there is a lot for you to learn yet… A good start would be limitations
of views.

27

If one choose to, one could always perform DML on a view courtesy of 'instead of' triggers or such.

Alternatively, one could look at the db as a, hmm, black box. The db only exposes itself as a set of RPC calls (aka store procedures or such). Clients only interact with the db through these. No free form queries or anything. As always, YMMV.

···

On Nov 14, 2010, at 7:55 PM, Skye Shaw!@#$ wrote:

On Nov 12, 8:47 am, Mike Stephens <rub...@recitel.net> wrote

Databases are supposed to be designed with external schemas ie you never
program to a base table...ever! You program to views

What happens when I want to make an update :frowning:

28

Skye Shaw!@#$ wrote in post #961372:

Databases are supposed to be designed with external schemas ie you never
program to a base table...ever! You program to views

What happens when I want to make an update :frowning:

Did a bit of research last night. These databases have some ability to
update views:

Oracle
DB2
Jet
IDMS

I'm sure there are more.

People on this channel may be unaware of what databases can do. I
believe for a long time MySQL did not have views at all. Or subqueries
for that matter. Mickey Mouse web applications might be fine with a
handful of tables, but in corporate contexts it is normal to see 100 or
even a 1000 tables in a database. Managing all this via ORM approaches
might be more difficult than at first appears. It's the difference
between driving your car to work and running an airline.

···

On Nov 12, 8:47am, Mike Stephens <rub...@recitel.net> wrote

--
Posted via http://www.ruby-forum.com/\.

29

SQL isn't necessarily abysmal it just does not lend itself to the kinds
of things application developers need to do in the application layer.
SQL is very nice as long as you don't try to do things it was not made
for. Not that SQL as a language is not in need of improvements. The
way some queries *don't* work like one would expect when you apply a
range is one such thing.

···

On 12/02/2010 07:22 PM, Tony Arcieri wrote:

On Fri, Nov 12, 2010 at 9:47 AM, Mike Stephens <rubfor@recitel.net> 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.

On the contrary, ORMs let people utilize this wealth of domain knowledge in
SQL databases without having to touch the abysmal puddle of vomit that is
SQL, and using familiar object interfaces through metalinguistic
abstraction.

ORMs rock, and they're a stepping stone towards a future where distributed
"NoSQL" data stores will be a satisfactory replacement for the dinosaurs
that are SQL databases.

That said, I still use MySQL as our only database.

30

Hi I use Ubuntu, can you tell me where to find the IE script interpreter for
Ubuntu? I looked for it on the Microsoft site, but all I found were
references to a web browser.

···

On Fri, Dec 3, 2010 at 9:40 AM, Mike Stephens <rubfor@recitel.net> wrote:

Rimantas Liubertas wrote in post #965923:
And
> win32ole
> won't fire, because I am on OS X.
>
I think we all understand that if you're on different platforms you have
to translate what I said. It would be quite pointless for me to start
listing all software on all platforms. Normally people know this.

--
http://richardconroy.blogspot.com | http://twitter.com/RichardConroy

31

A DSL *is* a different language. That's sorta the point.

If anything, it's people who insist that SQL, and *only* SQL, should be
used for DB access that have a hang-up about using different languages
for different tasks. A database ORM provides a DSL that specifically
deals with a particular set of conditions at the point where Ruby and SQL
intersect. It is, in short, an attempt to make a "best tool for the job"
rather than rely on trying to get two different tools, each specific to
opposite ends of a spectrum, to mix together without making your life
suck.

···

On Sat, Dec 04, 2010 at 07:25:14AM +0900, Mike Stephens wrote:

Ryan Davis wrote in post #966039:
>
> What does this have to do with the "ORM's Don't Do It" thread?
>
> Don't thread hijack. Man up and hit "new message".

This is to do with a current trend - domain specific languages.

You can try and write applications in a single language. ORMs try and
make relational databases look like Ruby.

The alternate view is to say an application should use a set of
different languages each optimal for the task at hand.

--
Chad Perrin [ original content licensed OWL: http://owl.apotheon.org ]

32

Solution #5 seems to be pretty much nailed by Sequel (the gem), IMHO.

···

On 11/12/2010 12:56 PM, Petite Abeille wrote:

http://blogs.tedneward.com/2006/06/26/The+Vietnam+Of+Computer+Science.aspx

33

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!!!

--
Posted via http://www.ruby-forum.com/\.

34

Petite Abeille 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&gt;\.

Clifford Heath, Data Constellation, http://dataconstellation.com
Agile Information Management and Design.

···

On Nov 12, 2010, at 6:18 PM, Phillip Gawlowski wrote:

35

[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 Sat, Nov 13, 2010 at 05:56:19AM +0900, Petite Abeille wrote:

On Nov 12, 2010, at 6:18 PM, Phillip Gawlowski wrote:

--
Chad Perrin [ original content licensed OWL: http://owl.apotheon.org ]

36

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. :wink:

An oldie, but a goodie :slight_smile:

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

···

On Fri, Nov 12, 2010 at 9:56 PM, Petite Abeille <petite.abeille@gmail.com> wrote:

On Nov 12, 2010, at 6:18 PM, Phillip Gawlowski wrote:

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

37

Petite Abeille wrote in post #961384:

Alternatively, one could look at the db as a, hmm, black box. The db
only exposes itself as a set of RPC calls (aka store procedures or
such). Clients only interact with the db through these. No free form
queries or anything. As always, YMMV.

I suspect this is what most programmers do as most databases seem to be
very poor at views, and particularly at updatable views. (Jet curiously
is really rather smashing at this).

This all comes from the Three Schema Architecture, which proposes you
have a logical model (the base tables) which represents the objects in
your domain, an internal model which is how your data is physically
stored and an external model which is in a format relevant and
convenient for your application. When the relational model was defined
(by ANSC),no internal schema structure was covered (almost always we use
the relations of the logical model more-or-less). An external schema was
however defined. The expectation was you would write your programs to
views.

···

--
Posted via http://www.ruby-forum.com/\.

38

It's actually rather easy to run an airline (as easy as any transport
corporation). It's difficult to get the infrastructure going, however.

So, pray tell, in how far is it easy to deal with 100, or even 1000
different tables per database[0] (BTW, when you say "database" do you
mean the engine, or actual database entities. IOW: 1000 tables per
schema, or 1000 tables in total) in any sensible, or at least easy-ish
way? Instead of bashing ORM, offer suggestions, for once.

[0]Not forgetting that the only people who have access to all tables
in any given database are only a select few, simply for privacy and
security reasons.

···

On Wed, Nov 17, 2010 at 2:34 PM, Mike Stephens <rubfor@recitel.net> wrote:

Skye Shaw!@#$ wrote in post #961372:

People on this channel may be unaware of what databases can do. I
believe for a long time MySQL did not have views at all. Or subqueries
for that matter. Mickey Mouse web applications might be fine with a
handful of tables, but in corporate contexts it is normal to see 100 or
even a 1000 tables in a database. Managing all this via ORM approaches
might be more difficult than at first appears. It's the difference
between driving your car to work and running an airline.

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

39

Strongly disagree... as far as a declarative query language goes, something
like LINQ is really what SQL should've been. SQL might as well be FLOW-MATIC

···

On Thu, Dec 2, 2010 at 5:41 PM, Kevin <darkintent@gmail.com> wrote:

SQL isn't necessarily abysmal... SQL is very nice as long as you don't try
to do things it was not made for.

--
Tony Arcieri
Medioh! Kudelski

40

Richard Conroy wrote in post #965936:

>>
Hi I use Ubuntu, can you tell me where to find the IE script interpreter
for
Ubuntu? I looked for it on the Microsoft site, but all I found were
references to a web browser.

I guess you must be new to computing. Microsoft is a big company in
Redmond. Their stuff is the most widely used by far but has limited
cross compatibility. Ubuntu is made by another company not based in
Redmond. You have to use other applications on it, so ignore any remarks
about Excel and as regards a browser, with eg WATIR I suggest you use
Firefox - http://www.mozilla-europe.org/en/firefox/

···

--
Posted via http://www.ruby-forum.com/\.