ORMs comparisons/complaints.


J

Jerry Stuckle

So if you'll stop ruining other newsgroups with off-topic posts and full
quotes, we'd be grateful.

This was about ORM-mapping in general and intentionally mentioned "non-
Java ORM" - with the PHP newsgroup included, I hope you're able to count
add 1 and 1 together and comprehend that this means PHP people were
asked their opinion. Your "The author didnt' ask a PHP-Question" thread-
takeover is off topic and I'd be grateful if you stopped this bullshit
now and forever, thanks.

F'up set to the newsgroup where you belong, scorefile adjusted, thank
you.

Ah, another well-known TROLL who thinks he knows what belongs in a
newsgroup he never has even looked at. But then I see that's pretty
normal for you, also. And like other trolls, you use a 'nym and free
email address because you're terrified someone will recognize you. I
understand - I would be, too, if I had your history.

But let me see if I can make this so simple even a TROLL can understand
it (probably not - TROLLS are too dense to understand much of anything).
This is for questions about the PHP LANGUAGE, not PHP PRODUCTS. See
the charter for this newsgroup.

So stop the bullshit, TROLL. And fupped back to the TROLL newsgroup,
where you belong.

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
(e-mail address removed)
==================
 
Ad

Advertisements

G

Graham Hobbs

"Jerry Stuckle" wrote in message

So let me get it straight then Jez:

1. Anyone who disagrees with you is a troll.
2. You own c.l.p and you alone decides who posts there and what topics are
acceptable.
3. Anyone who uses Gmail or "free" email services is hiding something and is
a troll.
4. Anyone who chooses not to use their real name is hiding something and is
a troll.
5. You have no issue deciding where follow-ups should go because you know
best and you are more important than anyone else.

So have I got all that right? Anything else?

Here's something you need to understand yourself:

YOU DO NOT OWN THE INTERNET AND YOU DO NOT OWN THE NEWSGROUP.

Just because *you* think something is OT or you don't like their nick or the
fact that they use Gmail does not give you the right to evict them from
*your* newsgroup. The net is FREE as in free-speech and in that there are
no "newsgroup cops" or whatever the hell you think you are.

Of course you are also FREE to express your *opinion*, but you do not in any
way, shape or form have any right to decide who posts or what is posted.

Why? Because...

YOU DO NOT OWN THE INTERNET AND YOU DO NOT OWN THE NEWSGROUP.

May I remind you that this all started because I called you out on your
narcissist complex and troll-ish behaviour where you attempted to force the
entire thread into a newsgroup that *you* deemed more appropriate. Where do
you get off doing that?

As I said a while ago, just post your certificate of ownership of c.l.p and
all this can be put to bed. Don't have one? Then stop it behaving as
though you do.

BTW:

YOU DO NOT OWN THE INTERNET AND YOU DO NOT OWN THE NEWSGROUP.
---
Hello qu0ll,

Just browsing a couple of c.l.p threads I find the likes of Michael
Vilain, Jerry Stuckle, Christof Michael Becker, Denis McMahon, Tim
Streater, others .. you are simply 'Queue you zero el el'.

Is there a reason you don't use your real name?

Graham Hobbs
 
J

Jerry Stuckle

---
Hello qu0ll,

Just browsing a couple of c.l.p threads I find the likes of Michael
Vilain, Jerry Stuckle, Christof Michael Becker, Denis McMahon, Tim
Streater, others .. you are simply 'Queue you zero el el'.

Is there a reason you don't use your real name?

Graham Hobbs

Graham, haven't you learned by now? Trolls NEVER use their real names.
They're too chicken to let anyone know who they really are.


--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
(e-mail address removed)
==================
 
T

The Natural Philosopher

"Wanja Gayk" wrote in message news:[email protected]
Please notice you're have allowed yourself to be dragged into the
troll's game by responding more often than necessary, which is what
allowed the troll to hijack the thread in the first place.
I personally don't have the greatest trouble with someone putting a
troll right once and ignoring him thereafter, but this one is going on
for too long in my opinion, and hopefully in yours too.
May I, with no further argument, request an EOD here, please?

Well said. EOD.

--
And loving it,

-Qu0ll (Rare, not extinct)
_________________________________________________
(e-mail address removed)
[Replace the "SixFour" with numbers to email me]

since the main protagonists are already plonked here, I only get to see
the reactions.

The answer is simple, plonk the protagonists yourself.


--
Ineptocracy

(in-ep-toc’-ra-cy) – a system of government where the least capable to
lead are elected by the least capable of producing, and where the
members of society least likely to sustain themselves or succeed, are
rewarded with goods and services paid for by the confiscated wealth of a
diminishing number of producers.
 
G

Graham Hobbs

"Graham Hobbs" wrote in message


Right, so you also agree that only those who have posted regularly in one
particular group have either the right to post there or comment on other
posts? Or that newcomers can be treated as though they are second-class
citizens? What kind of group is this exactly? Because I am not aware of
such rules in any *other* group!
 
A

Arved Sandstrom

Hey everyone,

This is cross-posted to cl.java.programmer and cl.php.

I've been doing some thinking about my experiences with various ORMs,
both positive and negative. I find that I often stretch systems to
there limits, and end up doing a lot of meta-programming to solve
problems that I've always felt should have been solved by the core
libraries. Mostly to follow DRY and KISS principals in the core
business code.

I'm curious if others' have found the same things I have, or if they've
been satisfied doing things other ways, and if so what ORMs they use.

I've had experience with the following Java ORMs:
* Hibernate (version 3, using Annotations for instance)
* Ibatis (many years ago, don't remember the version. around 2006)
* Straight JDBC. Not exactly an ORM :)

And then one non-Java ORM: Doctrine, which is modeled after Hibernate,
including most of its flaws, but missing some of its features.


So, my question to the groups, what ORMs have you used, and what did you
like and hate about each of them? I'm not trying to start a flame war,
so please keep it to personal experiences with projects which used them.

I'm interested in use-cases from simple small one-off applications to
complex enterprise-level systems, and highly-scalable systems.

Please include details like "it's easier to maintain <x> type of changes
with our approach, but <y> is very difficult" etc...

Thanks for your consideration,
Daniel.

Java ORMs:

Hibernate - but not recently, and even when I used it last mostly in its
first JPA incarnation, and not much. Last use of native Hibernate many
years ago;

Straight JDBC - still quite a lot. Not an ORM, as you say;

iBatis/MyBatis - a fair bit;

TopLink/TopLink Essentials (TLE)/EclipseLink - a lot. Native for first
two + JPA, JPA through EclipseLink.

My ideas about ORMs have been informed a fair bit by using them in other
languages, so although I won't blur the issue by mentioning them, their
use will influence my opinions.

*Industry* use of the various Java ORMs above: native Hibernate a long
time ago, Hibernate JPA just a little, native TopLink a long time ago,
TLE and EclipseLink a great deal for JPA. Non-ORM: straight JDBC a lot
and since it got invented.

I prefer JPA as an ORM API. I have no strong thoughts on Hibernate JPA
versus EclipseLink JPA...I had to settle on one and chose
TLE/EclipseLink. I have investigated JDO - it is more general than JPA
insofar as it doesn't require a RDBMS datastore - but no industry
projects I've been involved with (in 15 years or more) have been
anything but RDBMS.

JPA disadvantages (IMHO): relatively high bar to entry...not that simple
to use well, and especially now with JPA 2 so many features that a
novice can get discombobulated: IOW, not simple.

JPA advantages: pretty much the reverse of the immediate above -
efficient and powerful if you know what you are doing. "Knowing what you
are doing" means not relying on IDEs, understanding lifetimes, and
knowing what features you should not usually use.

If I had to not use JPA I'd use straight JDBC, and do.

AHS
 
Ad

Advertisements

A

Arne Vajhøj

If you want, you can talk all you want about it in c.l.j.p. But this
does not belong in c.l.p.

So you keep saying.

But just saying it does not make it correct.

I just googled and found the original comp.lang.php charter
from 2002.

I says:

"Since database connectivity is a large part of PHP, it will
be considered topical in comp.lang.php."

Unless you have changed the charter since then (Google can not
find that, but that does not prove that it does not exist), then
that means that ORM in PHP is on topic for comp.lang.php.

Arne
 
A

Arne Vajhøj

But let me see if I can make this so simple even a TROLL can understand
it (probably not - TROLLS are too dense to understand much of anything).
This is for questions about the PHP LANGUAGE, not PHP PRODUCTS. See
the charter for this newsgroup.

The only charter Google can find say that database connectivity from PHP
(which is what a PHP ORM is) is on topic.

What charter are you referring to?

Arne
 
A

Arne Vajhøj

Yes, with your presence has added one more TROLL to this newsgroup. We
don't need you. Go back and ruin your java newsgroup.
FUP'd to comp.lang.java.programmer, although I know the TROLL will
change it again. Why do you guys even put up with him?

Because he does not troll.

He is a bit optimistic about the future for JavaFX, but that is
not trolling.

Feel free to google yourself.

Arne
 
A

Arne Vajhøj

"Arne Vajhøj" wrote in message


No, no, no Arne! Don't throw facts at a troll, they do not know how to
handle them!

I found this which I think is a more recent c.l.p charter and is the one
that's obviously in effect now:

"Posts are considered topical for comp.lang.php if they relate to PHP
directly or indirectly but only if Jerry Stuckle approves of either the
post, the content or the poster.

Note: Jerry (who is the official owner of c.l.p) does *NOT* permit any
posts which have any of the following attributes:

1. They are posted by someone who has never posted in c.l.p before.
2. The poster uses a Gmail address.
3. The poster chooses not to publish their actual name.
4. The poster or post makes Jerry look like a fool.

Please email Jerry directly if any of this is not clear."

Unfortunately point (4) results in most posts being declared spam by
said owner.

Please don't take a job within international diplomacy.

:)

Arne
 
A

Arne Vajhøj

That leaves many ORM utilities as too enormous, too complex, too slow,
and still a poor fit for SQL. I see ORM as potentially being an
excellent fit for document stores but I have little experience with
those.

????

What would be the point of an ORM that maps to a relational data model
in connection with a non-relational database?

Arne
 
Ad

Advertisements

A

Arne Vajhøj

First of all you need to mention what ORMs are designed for. They are
intended to make SQL databases suitable for OO programming style and/or
non-relational data models. At the end OO expressions are turned into
SQL and then to an execution plan.
From that you can see that there is exactly one thing superfluous in
this scenario: SQL. It is the bottleneck where all expressions must fit
to. But it does not add any functionality, quite the contrary. It is
just a emulation level for compatibility, like a SATA adapter enables a
SATA drive to be used with an IDE port.

You see, I am not really a friend of ORM. If a relational data model
does not fit your needs, you first should consider to use a non
relational database, rather than to normalize the data model to fit into
a relational DB, and use an ORM to hide that from the application layer.

Yes and no.

If you could get non-relational databases with same transactional
support, same tools, same vendor support etc..

And if all access to the database is OO based.

Then that would be obvious.

But the non-relational databases has not reached the same maturity level
(as a summary term for the above) as relational databases.

And it is common to have the same databases used by modern OO based
software also to be used by non-OO legacy software (like 20 year
old COBOL programs).
ORMs are known to slow things down. I don't think that this is true in
general. But the ORM layer makes some trivial looking expressions
amazingly complex. So it is not that easy for the programmer to estimate
the complexity of a code block, without knowledge about the entire ORM
layer and the base data model in SQL. In fact I have redesigned many
code parts because of this.

Oh - I have seen my share of that.

It should be mandatory for developers writing code using ORM to do some
testing with the logging of actual SQL statements executed turned on. It
reveals what is going on without having to know so much about the inside
of the ORM.
Of course, if you are stuck with an SQL DB for some reason and you need
to adapt to an OO application layer ORM might be a choice. But if the
data model in the DB is not intended for ORM usage, you won't get happy,
because there are almost always properties of the data model that are
not correctly modeled in SQL.

It seems as if very large parts of the Java, .NET and Ruby worlds
are able to make it work.

Arne
 
A

Arne Vajhøj

The JDBC API is also really, really bad, but you can escape much of
that pain by using a helper like JDBC Template or similar.

JDBC is a low level database API.

And it is very similar to ODBC, ADO, ADO.NET, mysqli etc..

I don't think it can be that much different for a low level
API.

Arne
 
A

Arne Vajhøj

I did several stabs at ORMs in some small toy projects but have mainly
use ORMs working on existing projects using ORMs (both Hibernate and
Toplink) that where performing extremely poorly and had become almost
impossible to maintain and extend. I was then called in to take the ORM
out of the system as much as possible. This always consisted of creating
alternative tools for interacting with the RDBMS that the programmers
could use to rewrite the must critical and/or problematic system parts.

Most places they are actually able to get ORM working.
So you could say I have mainly negative experiences I could share. To
put it bluntly: I think ORM is a bad idea in general. I dig OOP for
modelling the transient behaviour of a running program but find the
relational model far superior for modelling data. I also find it
beneficial in general to think of data and programs working on data as
separate things.

ORM is a mechanism to help you do it the other way around, and a poor
one at it. If you want to persist objects use an object database or
serialize to some NoSQL store. If you want structured data in an RDBMS
don't degrade it into a pile of persisted objects.

I am not quite sure that I can follow you.

If you want OO for the code and you want the relational database,
then you must do a mapping between the two.

You can either hand write a lot of code or use an ORM.

Typical using an ORM is faster because it means less code.

You may not be able to use ORM 100%, but then use it 90% and
hand write code for the remaining 10%.

Arne
 
J

Jerry Stuckle

The only charter Google can find say that database connectivity from PHP
(which is what a PHP ORM is) is on topic.

What charter are you referring to?

Arne

ORM is not database connectivity. But you obviously are too stoopid to
understand there is a difference.

FYI. Database connectivity is discussed in the PHP manual (see
www.php.net). ORM is NOT.

But then I've found some Java programmers aren't very smart.

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
(e-mail address removed)
==================
 
J

Jerry Stuckle

So you keep saying.

But just saying it does not make it correct.

I just googled and found the original comp.lang.php charter
from 2002.

I says:

"Since database connectivity is a large part of PHP, it will
be considered topical in comp.lang.php."

Unless you have changed the charter since then (Google can not
find that, but that does not prove that it does not exist), then
that means that ORM in PHP is on topic for comp.lang.php.

Arne

ORM is not database connectivity. But you're too stoopid to understand
the difference. Just like some other Java programmers.


--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
(e-mail address removed)
==================
 
Ad

Advertisements

S

Silvio

On 12/23/2013 7:25 AM, Silvio wrote:

Most places they are actually able to get ORM working.


I am not quite sure that I can follow you.

If you want OO for the code and you want the relational database,
then you must do a mapping between the two.

You can either hand write a lot of code or use an ORM.

Typical using an ORM is faster because it means less code.

You may not be able to use ORM 100%, but then use it 90% and
hand write code for the remaining 10%.

Arne

ORMs are good at what they where invented for: serializing an object and
resurrecting it at a later point in time. That means you have to design
your system and its underlying data as a collection of objects with
(encapsulated) member data. Using that approach the lifetime of an
object instance must be able to extend the actual running span of the
program. That requires serialization/resurrection by definition. Apart
from the fact that I think that this is a bad approach on its own, to
constrain memory usage objects need to be put to sleep by default and be
resurrected only when they are accessed. This makes the approach even
more blurred and needlessly complex, bringing stuff like caching and
managing/synchronizing duplicate object instances across concurrently
running program instances into the picture.

To make things worse almost no system only needs single object
instances. Almost any practical system needs counts, averages etc. which
could be done with a query on an RDBMS or by traversing object instances
IF THEY WHERE REAL INSTANCES. Since doing the latter with an ORM would
require resurrecting enormous amounts of instances for practical reasons
you have to pour water into the wine and do atypical stuff like joins
and aggregate queries through the ORM. I know they CAN do this but that
is no more than a wart on such systems since they contradict the primary
goal of an ORM. This is also the area where ORMs failed in the projects
I talked about. It's not that the ORM can not do it, it just can not do
it sufficiently well even with help from the most experienced experts we
could find.

I still think the best approach for most systems is to design a separate
and independent data store that covers the problem domain which is
completely isolated from the systems that implement data extractions,
processes and data storage. I do not manually write code to serialize
object instances since I do not serialize them in the first place. Such
a data store can be an RDBMS but if so desired a NoSQL thingy or even a
file system could do well. Using an RDBMS gives the additional advantage
that the data is readily accessible for standard reporting and ETL tools.
 
A

Arne Vajhøj

ORM is not database connectivity.

If it is what the PHP code is using to access the database, then
it is providing database connectivity.
But you're too stoopid to understand
the difference.

Name calling is not a very convincing argumentation.

Arne
 
D

Daniel Pitts

On 12/30/13 5:38 AM, Silvio wrote:
[snip]
To make things worse almost no system only needs single object
instances. Almost any practical system needs counts, averages etc. which
could be done with a query on an RDBMS or by traversing object instances
IF THEY WHERE REAL INSTANCES. Since doing the latter with an ORM would
require resurrecting enormous amounts of instances for practical reasons
you have to pour water into the wine and do atypical stuff like joins
and aggregate queries through the ORM. I know they CAN do this but that
is no more than a wart on such systems since they contradict the primary
goal of an ORM. This is also the area where ORMs failed in the projects
I talked about. It's not that the ORM can not do it, it just can not do
it sufficiently well even with help from the most experienced experts we
could find.
This is a good point, and it was something niggling in subconscious.
This is where I've always struggled with ORMs, but I never consciously
acknowledged that the difficulty was in utilizing the power of the "R"
in The ORM.
I still think the best approach for most systems is to design a separate
and independent data store that covers the problem domain which is
completely isolated from the systems that implement data extractions,
processes and data storage. I do not manually write code to serialize
object instances since I do not serialize them in the first place. Such
a data store can be an RDBMS but if so desired a NoSQL thingy or even a
file system could do well. Using an RDBMS gives the additional advantage
that the data is readily accessible for standard reporting and ETL tools.
This is one approach. I think one of the major "features" of most ORM
implementations is that they attempt to abstract away the actual RDBMS
layer to the point where you feel "dirty" trying to access it in any
meaningful way. This does provide some value in portability, but many
applications rarely need this portability of RDBMS, and more often
benefit from special features of the particular RDBMS chosen.

I once actually had to "extend" (read hack) Hibernate to allow the
"group_concat" MySQL call in an HQL query.
 
Ad

Advertisements

A

Arne Vajhøj

ORM is not database connectivity.

It is what the application is using to connect to the database - that
is connectivity.
But you obviously are too stoopid to
understand there is a difference.

FYI. Database connectivity is discussed in the PHP manual (see
www.php.net). ORM is NOT.

If the charter said that only what is covered in the PHP manual is
on topic, then ORM was definitely off topic.

But it does not. It includes database connectivity without making
any restrictions on it being included in PHP and/or being documented
in the PHP documentation.

That means that PEAR DB stuff, ORM etc. are on topic.

Live with it or get the charter changed.
But then I've found some Java programmers aren't very smart.

Said the person that considered ORM's to be applications.

Arne
 

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

Top