| Re: ORMs comparisons/complaints. [message #184390 is a reply to message #184328] |
Mon, 30 December 2013 04:20   |
Arne Vajhøj
Messages: 27
Registered: December 2013
Karma: 0
|
Junior Member |
|
|
On 12/23/2013 8:22 AM, Leif Roar Moldskred wrote:
> 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
|
|
|
|
| Re: ORMs comparisons/complaints. [message #184391 is a reply to message #184387] |
Mon, 30 December 2013 04:21 |
Qu0ll
Messages: 15
Registered: December 2013
Karma: 0
|
Junior Member |
|
|
"Arne Vajhøj" wrote in message
news:52c0f159$0$297$14726298(at)news(dot)sunsite(dot)dk...
> Please don't take a job within international diplomacy.
True, I concede that was a bit below the belt. But very little annoys me
more than someone who attempts to censor free speech.
I apologise for going a little over-the-top. Sometimes passion for fairness
and fair-play makes me do things in the heat of the moment I later regret...
--
And loving it,
-Qu0ll (Rare, not extinct)
_________________________________________________
Qu0llSixFour(at)gmail(dot)com
[Replace the "SixFour" with numbers to email me]
|
|
|
|
| Re: ORMs comparisons/complaints. [message #184392 is a reply to message #184325] |
Mon, 30 December 2013 04:27 |
Arne Vajhøj
Messages: 27
Registered: December 2013
Karma: 0
|
Junior Member |
|
|
On 12/23/2013 7:25 AM, Silvio wrote:
> 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
|
|
|
|
| Re: ORMs comparisons/complaints. [message #184393 is a reply to message #184386] |
Mon, 30 December 2013 04:40 |
Qu0ll
Messages: 15
Registered: December 2013
Karma: 0
|
Junior Member |
|
|
"Arne Vajhøj" wrote in message
news:52c0f061$0$294$14726298(at)news(dot)sunsite(dot)dk...
> He is a bit optimistic about the future for JavaFX, but that is
> not trolling.
A bit optimistic? Nah, JavaFX is the future of cross-platform app
development and will also bring about world peace ;-)
--
And loving it,
-Qu0ll (Rare, not extinct)
_________________________________________________
Qu0llSixFour(at)gmail(dot)com
[Replace the "SixFour" with numbers to email me]
|
|
|
|
| Re: c [message #184397 is a reply to message #184384] |
Mon, 30 December 2013 13:03 |
Jerry Stuckle
Messages: 2598
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
On 12/29/2013 10:51 PM, Arne Vajhøj wrote:
> On 12/24/2013 8:49 AM, Jerry Stuckle wrote:
>> 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
>
>
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.
jstucklex(at)attglobal(dot)net
==================
|
|
|
|
| Re: ORMs comparisons/complaints. [message #184398 is a reply to message #184382] |
Mon, 30 December 2013 13:04 |
Jerry Stuckle
Messages: 2598
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
On 12/29/2013 10:46 PM, Arne Vajhøj wrote:
> On 12/22/2013 4:34 PM, Jerry Stuckle wrote:
>> On 12/22/2013 4:20 PM, Arne Vajhøj wrote:
>>> On 12/22/2013 4:09 PM, Jerry Stuckle wrote:
>>>> On 12/22/2013 4:04 PM, Arne Vajhøj wrote:
>>>> > On 12/22/2013 3:47 PM, Jerry Stuckle wrote:
>>>> >> On 12/22/2013 3:38 PM, Arne Vajhøj wrote:
>>>> >>> On 12/22/2013 3:17 PM, Jerry Stuckle wrote:
>>>> >>>> On 12/22/2013 2:05 PM, Daniel Pitts wrote:
>>>> >>>>> 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...
>>>> >>>>
>>>> >>>> Is there a PHP question in there? I don't see one...
>>>> >>>
>>>> >>> Doctrine is PHP. And the question is open ended so other PHP
>>>> >>> ORM's could be included in discussion.
>>>> >>
>>>> >> I still don't see a PHP question here. I see some product
>>>> >> questions -
>>>> >> which would be better suited in a newsgroup for those applications.
>>>> >>
>>>> >> Just because something uses PHP does not mean it is appropriate for a
>>>> >> PHP language newsgroup.
>>>> >>
>>>> >> But I know some people don't believe in segregation of newsgroups and
>>>> >> think anything should be able to be asked in any newsgroup.
>>>> >
>>>> > ORM's are not applications. They are libraries.
>>>> >
>>>> > And since it is question asking for comparison, then a group
>>>> > for a specific library is not a good choice.
>>>> >
>>>> > Instead a group with people with experience and interest in
>>>> > different ways of database access from PHP is needed.
>>>> >
>>>> > comp.lang.php does not seem that far fetched.
>>>> >
>>>> > Obviously comp.lang.php.databaseaccess or
>>>> > comp.lang.php.databaseaccess.orm
>>>> > would be even better if such exists.
>>>>
>>>> Yes, an ORM-related newsgroup would be more appropriate. There you
>>>> have
>>>> people who know the advantages and disadvantages of various ORM's.
>>>
>>> ORM's are language specific. So it would need to be a PHP ORM group
>>> to cover PHP.
>>>
>>> Does one exist?
>>>
>>>> Few, if any, in the language-related newsgroups will have used an ORM,
>>>> and if they have, they have very limited experience.
>>>
>>> That depends on the language.
>>>
>>> In languages like Java and C# it would be >90% that have used an ORM.
>>>
>>> It is probably much less in PHP as ORM's are not as widely used
>>> in the PHP world.
>>>
>>> But I suspect that Daniel even may be interested in knowing more
>>> about why it is so.
>>
>> 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
>
>
>
>
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.
jstucklex(at)attglobal(dot)net
==================
|
|
|
|
| Re: ORMs comparisons/complaints. [message #184400 is a reply to message #184392] |
Mon, 30 December 2013 13:38 |
Silvio
Messages: 5
Registered: December 2013
Karma: 0
|
Junior Member |
|
|
On 12/30/2013 05:27 AM, Arne Vajhøj wrote:
> 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.
|
|
|
|
| Re: ORMs comparisons/complaints. [message #184401 is a reply to message #184398] |
Mon, 30 December 2013 17:32 |
Arne Vajhøj
Messages: 27
Registered: December 2013
Karma: 0
|
Junior Member |
|
|
On 12/30/2013 8:04 AM, Jerry Stuckle wrote:
> On 12/29/2013 10:46 PM, Arne Vajhøj wrote:
>> On 12/22/2013 4:34 PM, Jerry Stuckle wrote:
>>> On 12/22/2013 4:20 PM, Arne Vajhøj wrote:
>>>> On 12/22/2013 4:09 PM, Jerry Stuckle wrote:
>>>> > On 12/22/2013 4:04 PM, Arne Vajhøj wrote:
>>>> >> On 12/22/2013 3:47 PM, Jerry Stuckle wrote:
>>>> >>> On 12/22/2013 3:38 PM, Arne Vajhøj wrote:
>>>> >>>> On 12/22/2013 3:17 PM, Jerry Stuckle wrote:
>>>> >>>>> On 12/22/2013 2:05 PM, Daniel Pitts wrote:
>>>> >>>>>> 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...
>>>> >>>>>
>>>> >>>>> Is there a PHP question in there? I don't see one...
>>>> >>>>
>>>> >>>> Doctrine is PHP. And the question is open ended so other PHP
>>>> >>>> ORM's could be included in discussion.
>>>> >>>
>>>> >>> I still don't see a PHP question here. I see some product
>>>> >>> questions -
>>>> >>> which would be better suited in a newsgroup for those applications.
>>>> >>>
>>>> >>> Just because something uses PHP does not mean it is appropriate
>>>> >>> for a
>>>> >>> PHP language newsgroup.
>>>> >>>
>>>> >>> But I know some people don't believe in segregation of newsgroups
>>>> >>> and
>>>> >>> think anything should be able to be asked in any newsgroup.
>>>> >>
>>>> >> ORM's are not applications. They are libraries.
>>>> >>
>>>> >> And since it is question asking for comparison, then a group
>>>> >> for a specific library is not a good choice.
>>>> >>
>>>> >> Instead a group with people with experience and interest in
>>>> >> different ways of database access from PHP is needed.
>>>> >>
>>>> >> comp.lang.php does not seem that far fetched.
>>>> >>
>>>> >> Obviously comp.lang.php.databaseaccess or
>>>> >> comp.lang.php.databaseaccess.orm
>>>> >> would be even better if such exists.
>>>> >
>>>> > Yes, an ORM-related newsgroup would be more appropriate. There you
>>>> > have
>>>> > people who know the advantages and disadvantages of various ORM's.
>>>>
>>>> ORM's are language specific. So it would need to be a PHP ORM group
>>>> to cover PHP.
>>>>
>>>> Does one exist?
>>>>
>>>> > Few, if any, in the language-related newsgroups will have used an ORM,
>>>> > and if they have, they have very limited experience.
>>>>
>>>> That depends on the language.
>>>>
>>>> In languages like Java and C# it would be >90% that have used an ORM.
>>>>
>>>> It is probably much less in PHP as ORM's are not as widely used
>>>> in the PHP world.
>>>>
>>>> But I suspect that Daniel even may be interested in knowing more
>>>> about why it is so.
>>>
>>> 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.
>
> 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
|
|
|
|
| Re: ORMs comparisons/complaints. [message #184402 is a reply to message #184400] |
Mon, 30 December 2013 17:36 |
Daniel Pitts
Messages: 68
Registered: May 2012
Karma: 0
|
Member |
|
|
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.
|
|
|
|
| Re: c [message #184403 is a reply to message #184397] |
Mon, 30 December 2013 17:40 |
Arne Vajhøj
Messages: 27
Registered: December 2013
Karma: 0
|
Junior Member |
|
|
On 12/30/2013 8:03 AM, Jerry Stuckle wrote:
> On 12/29/2013 10:51 PM, Arne Vajhøj wrote:
>> On 12/24/2013 8:49 AM, Jerry Stuckle wrote:
>>> 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?
>
> 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
|
|
|
|
| Re: c [message #184404 is a reply to message #184403] |
Mon, 30 December 2013 17:46 |
Jerry Stuckle
Messages: 2598
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
On 12/30/2013 12:40 PM, The well known TROLL Arne Vajhøj wrote:
> On 12/30/2013 8:03 AM, Jerry Stuckle wrote:
>> On 12/29/2013 10:51 PM, Arne Vajhøj wrote:
>>> On 12/24/2013 8:49 AM, Jerry Stuckle wrote:
>>>> 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?
>>
>> 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
>
>
The OP was asking about ORM packages. That is NOT "database
connectivity". But you're too stoopid to know the difference.
Applications and packages are best known by the people who wrote them;
second are people are use them. Neither are present on comp.lang.php.
But then you, who have never been on c.l.p., think you know better than
the regulars who have been here for years. How like the TROLL you are.
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex(at)attglobal(dot)net
==================
|
|
|
|
| Re: ORMs comparisons/complaints. [message #184405 is a reply to message #184401] |
Mon, 30 December 2013 17:47 |
Jerry Stuckle
Messages: 2598
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
On 12/30/2013 12:32 PM, The well-known TROLL Arne Vajhøj wrote:
> On 12/30/2013 8:04 AM, Jerry Stuckle wrote:
>> On 12/29/2013 10:46 PM, Arne Vajhøj wrote:
>>> On 12/22/2013 4:34 PM, Jerry Stuckle wrote:
>>>> On 12/22/2013 4:20 PM, Arne Vajhøj wrote:
>>>> > On 12/22/2013 4:09 PM, Jerry Stuckle wrote:
>>>> >> On 12/22/2013 4:04 PM, Arne Vajhøj wrote:
>>>> >>> On 12/22/2013 3:47 PM, Jerry Stuckle wrote:
>>>> >>>> On 12/22/2013 3:38 PM, Arne Vajhøj wrote:
>>>> >>>>> On 12/22/2013 3:17 PM, Jerry Stuckle wrote:
>>>> >>>>>> On 12/22/2013 2:05 PM, Daniel Pitts wrote:
>>>> >>>>>>> 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...
>>>> >>>>>>
>>>> >>>>>> Is there a PHP question in there? I don't see one...
>>>> >>>>>
>>>> >>>>> Doctrine is PHP. And the question is open ended so other PHP
>>>> >>>>> ORM's could be included in discussion.
>>>> >>>>
>>>> >>>> I still don't see a PHP question here. I see some product
>>>> >>>> questions -
>>>> >>>> which would be better suited in a newsgroup for those applications.
>>>> >>>>
>>>> >>>> Just because something uses PHP does not mean it is appropriate
>>>> >>>> for a
>>>> >>>> PHP language newsgroup.
>>>> >>>>
>>>> >>>> But I know some people don't believe in segregation of newsgroups
>>>> >>>> and
>>>> >>>> think anything should be able to be asked in any newsgroup.
>>>> >>>
>>>> >>> ORM's are not applications. They are libraries.
>>>> >>>
>>>> >>> And since it is question asking for comparison, then a group
>>>> >>> for a specific library is not a good choice.
>>>> >>>
>>>> >>> Instead a group with people with experience and interest in
>>>> >>> different ways of database access from PHP is needed.
>>>> >>>
>>>> >>> comp.lang.php does not seem that far fetched.
>>>> >>>
>>>> >>> Obviously comp.lang.php.databaseaccess or
>>>> >>> comp.lang.php.databaseaccess.orm
>>>> >>> would be even better if such exists.
>>>> >>
>>>> >> Yes, an ORM-related newsgroup would be more appropriate. There you
>>>> >> have
>>>> >> people who know the advantages and disadvantages of various ORM's.
>>>> >
>>>> > ORM's are language specific. So it would need to be a PHP ORM group
>>>> > to cover PHP.
>>>> >
>>>> > Does one exist?
>>>> >
>>>> >> Few, if any, in the language-related newsgroups will have used an
>>>> >> ORM,
>>>> >> and if they have, they have very limited experience.
>>>> >
>>>> > That depends on the language.
>>>> >
>>>> > In languages like Java and C# it would be >90% that have used an ORM.
>>>> >
>>>> > It is probably much less in PHP as ORM's are not as widely used
>>>> > in the PHP world.
>>>> >
>>>> > But I suspect that Daniel even may be interested in knowing more
>>>> > about why it is so.
>>>>
>>>> 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.
>>
>> 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
>
>
>
>
>
The truth hurts, doesn't it?
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex(at)attglobal(dot)net
==================
|
|
|
|
| Re: ORMs comparisons/complaints. [message #184406 is a reply to message #184398] |
Mon, 30 December 2013 18:20 |
Ricardo Palomaes
Messages: 1
Registered: December 2013
Karma: 0
|
Junior Member |
|
|
El 30/12/13 14:04, Jerry Stuckle escribió:
> ORM is not database connectivity. But you're too stoopid to
> understand the difference. Just like some other Java programmers.
NOW it is clear who's the troll.
|
|
|
|
| Re: ORMs comparisons/complaints. [message #184407 is a reply to message #184406] |
Mon, 30 December 2013 18:34 |
The Natural Philosoph
Messages: 993
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
On 30/12/13 18:20, Ricardo Palomaes wrote:
> El 30/12/13 14:04, Jerry Stuckle escribió:
>> ORM is not database connectivity. But you're too stoopid to
>> understand the difference. Just like some other Java programmers.
>
>
> NOW it is clear who's the troll.
>
>
what took you so long...
--
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.
|
|
|
|
| Re: ORMs comparisons/complaints. [message #184408 is a reply to message #184407] |
Mon, 30 December 2013 19:27 |
Jerry Stuckle
Messages: 2598
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
On 12/30/2013 1:34 PM, The Natural Philosopher wrote:
> On 30/12/13 18:20, Ricardo Palomaes wrote:
>> El 30/12/13 14:04, Jerry Stuckle escribió:
>>> ORM is not database connectivity. But you're too stoopid to
>>> understand the difference. Just like some other Java programmers.
>>
>>
>> NOW it is clear who's the troll.
>>
>>
> what took you so long...
>
Ah, the anonymous troll speaks up again! He's afraid to use his real
name because he doesn't want us to find out he's neither a programmer or
the electrical engineer he claims to be.
And he doesn't like me because I've caught him too many times in his lies.
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex(at)attglobal(dot)net
==================
|
|
|
|
| Re: ORMs comparisons/complaints. [message #184409 is a reply to message #184401] |
Mon, 30 December 2013 19:45 |
Doug Miller
Messages: 171
Registered: August 2011
Karma: 0
|
Senior Member |
|
|
Arne Vajhøj <arne(at)vajhoej(dot)dk> wrote in news:52c1ae33$0$304$14726298(at)news(dot)sunsite(dot)dk:
> On 12/30/2013 8:04 AM, Jerry Stuckle wrote:
>> But you're too stoopid to understand the difference.
>
> Name calling is not a very convincing argumentation.
No, of course not, but it's the norm for Jerry whenever someone dares to disagree with him.
Just do what most of the rest of us who've been around this group for a while have already
done long ago: killfile him, and move on with your life.
|
|
|
|
| Re: ORMs comparisons/complaints. [message #184412 is a reply to message #184405] |
Mon, 30 December 2013 21:23 |
Qu0ll
Messages: 15
Registered: December 2013
Karma: 0
|
Junior Member |
|
|
"Jerry Stuckle" wrote in message news:l9sbjk$787$2(at)dont-email(dot)me...
> The truth hurts, doesn't it?
Well yes Jerry, clearly it does. Your own precious charter which you keep
referencing has shown you to be wrong (again).
You have now reduced yourself to labelling Java programmers (and anyone who
disagrees with you) as "stoopid" as well as being trolls.
At least there is no doubt in anyone's mind who the "troll" is here in this
hijacked thread.
I conceded I went too far in highlighting your arrogance, ignorance and
highly inappropriate behaviour but this in no way excuses your actions or
justifies them. I also apologised.
I suggest you take a slice of humble pie yourself.
You *really* need to take-away from this that you do not own the internet or
Usenet and if you continue to attempt your own form of censorship then
others will have a problem with that.
--
And loving it,
-Qu0ll (Rare, not extinct)
_________________________________________________
Qu0llSixFour(at)gmail(dot)com
[Replace the "SixFour" with numbers to email me]
|
|
|
|
| Re: ORMs comparisons/complaints. [message #184413 is a reply to message #184321] |
Mon, 30 December 2013 21:36 |
Arved Sandstrom
Messages: 9
Registered: December 2013
Karma: 0
|
Junior Member |
|
|
On 12/22/2013 08:11 PM, Kevin McMurtrie wrote:
> In article <%JGtu.29103$Wm1(dot)26832(at)fx17(dot)iad>,
> Daniel Pitts <newsgroup(dot)nospam(at)virtualinfinity(dot)net> wrote:
>
>> 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.
>
> I don't like ORM utilities much because they rarely model all of the
> complex relationships and behaviors, for better or worse, that may exist
> in SQL. You end up spending at least as much time working around those
> limitations as time initially saved.
>
> Simpler data works fine in ORM, but simpler data is isn't the complex
> task ORM tries to solve.
>
> 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.
>
To echo Arne's comment, an "excellent fit for document stores"??? How
so? If the document is well-modeled by a relational calculus, why model
it as a document? The current notion of a document is that of groups of
semi-structured or non-structured data that don't necessarily adhere to
any schema. Which is non-relational. There are fundamental differences here.
I haven't encountered the problems you have, apparently, with ORMs. Data
is complex, relational data is obviously just as complex, and any method
of querying or manipulating real relational data is often hard. And
considering major ORMs (not just Java), and the amount of educated
effort that has gone into them, there are not many people who are
well-advised to routinely use SQL directly if they have other
options...not unless they are RDBMS specialists, and that's what they do
for a living. Are you one? I'm not.
I'll say this: Java language limitations have hurt Java ORMs, and it's
not the fault of the ORM developers: I know a few of them. The JPA
Criteria API is a sign of the apocalypse. It's unfortunately informed by
folks who are both struggling with Java limitations and have experience
with native implementations. C# LINQ and Scala Squeryl are conceptually
light years ahead of Java ORMs.
AHS
--
When a true genius appears, you can know him by this sign:
that all the dunces are in a confederacy against him.
-- Jonathan Swift
|
|
|
|
| Re: ORMs comparisons/complaints. [message #184416 is a reply to message #184413] |
Mon, 30 December 2013 22:13 |
The Natural Philosoph
Messages: 993
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
On 30/12/13 21:36, Arved Sandstrom wrote:
> Data is complex, relational data is obviously just as complex, and any
> method of querying or manipulating real relational data is often hard.
> And considering major ORMs (not just Java), and the amount of educated
> effort that has gone into them, there are not many people who are
> well-advised to routinely use SQL directly if they have other
> options...not unless they are RDBMS specialists, and that's what they do
> for a living. Are you one? I'm not.
Ah. So mining is complex and labour intesive, so lets not learn how to
use an excavator, but instead develop tools to allow us to organise huge
gangs of navvies with picks and shovels, because that's easier for us
lazy shits than mastering the controls on a dump truck or draglinme
excavator.
If you cant manage relational databases, you shouldn't be messing with
big data.
--
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.
|
|
|
|
| Re: ORMs comparisons/complaints. [message #184418 is a reply to message #184402] |
Tue, 31 December 2013 00:26 |
Silvio
Messages: 5
Registered: December 2013
Karma: 0
|
Junior Member |
|
|
On 12/30/2013 06:36 PM, Daniel Pitts wrote:
> [snip]
> 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.
Portability across RDBMS-es is far more often planned for upfront than
it is actually used. But if it is really desired it can easily be
achieved in the data access layers. Not exactly rocket science, I have
done it in many systems.
Treating the data store as a separate deliverable gives a much more
important type of flexibility: being able too swap out (parts of)
applications that access the data since their interaction with that data
is well defined instead of an implicit artifact of the applications
themselves.
|
|
|
|
| Re: ORMs comparisons/complaints. [message #184420 is a reply to message #184416] |
Tue, 31 December 2013 02:09 |
Arved Sandstrom
Messages: 9
Registered: December 2013
Karma: 0
|
Junior Member |
|
|
On 12/30/2013 06:13 PM, The Natural Philosopher wrote:
> On 30/12/13 21:36, Arved Sandstrom wrote:
>> Data is complex, relational data is obviously just as complex, and any
>> method of querying or manipulating real relational data is often hard.
>> And considering major ORMs (not just Java), and the amount of educated
>> effort that has gone into them, there are not many people who are
>> well-advised to routinely use SQL directly if they have other
>> options...not unless they are RDBMS specialists, and that's what they do
>> for a living. Are you one? I'm not.
>
> Ah. So mining is complex and labour intesive, so lets not learn how to
> use an excavator, but instead develop tools to allow us to organise huge
> gangs of navvies with picks and shovels, because that's easier for us
> lazy shits than mastering the controls on a dump truck or draglinme
> excavator.
>
> If you cant manage relational databases, you shouldn't be messing with
> big data.
>
>
Identify yourself by your real name, doorknob. Maybe then you can put up
or shut up.
Learn spelling and grammar too - those skills help when you converse
with adults.
AHS
--
When a true genius appears, you can know him by this sign:
that all the dunces are in a confederacy against him.
-- Jonathan Swift
|
|
|
|
| Re: ORMs comparisons/complaints. [message #184426 is a reply to message #184420] |
Tue, 31 December 2013 11:30 |
The Natural Philosoph
Messages: 993
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
On 31/12/13 02:09, Arved Sandstrom wrote:
> On 12/30/2013 06:13 PM, The Natural Philosopher wrote:
>> On 30/12/13 21:36, Arved Sandstrom wrote:
>>> Data is complex, relational data is obviously just as complex, and any
>>> method of querying or manipulating real relational data is often hard.
>>> And considering major ORMs (not just Java), and the amount of educated
>>> effort that has gone into them, there are not many people who are
>>> well-advised to routinely use SQL directly if they have other
>>> options...not unless they are RDBMS specialists, and that's what they do
>>> for a living. Are you one? I'm not.
>>
>> Ah. So mining is complex and labour intesive, so lets not learn how to
>> use an excavator, but instead develop tools to allow us to organise huge
>> gangs of navvies with picks and shovels, because that's easier for us
>> lazy shits than mastering the controls on a dump truck or draglinme
>> excavator.
>>
>> If you cant manage relational databases, you shouldn't be messing with
>> big data.
>>
>>
> Identify yourself by your real name, doorknob. Maybe then you can put up
> or shut up.
>
> Learn spelling and grammar too - those skills help when you converse
> with adults.
>
So no counter argument, just an ad hominem attack.
You are Jerry Stuckle and I claim my $5.
> AHS
--
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.
|
|
|
|
| Re: ORMs comparisons/complaints. [message #184427 is a reply to message #184426] |
Tue, 31 December 2013 13:11 |
Jerry Stuckle
Messages: 2598
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
On 12/31/2013 6:30 AM, The Natural Philosopher wrote:
> On 31/12/13 02:09, Arved Sandstrom wrote:
>> On 12/30/2013 06:13 PM, The Natural Philosopher wrote:
>>> On 30/12/13 21:36, Arved Sandstrom wrote:
>>>> Data is complex, relational data is obviously just as complex, and any
>>>> method of querying or manipulating real relational data is often hard.
>>>> And considering major ORMs (not just Java), and the amount of educated
>>>> effort that has gone into them, there are not many people who are
>>>> well-advised to routinely use SQL directly if they have other
>>>> options...not unless they are RDBMS specialists, and that's what
>>>> they do
>>>> for a living. Are you one? I'm not.
>>>
>>> Ah. So mining is complex and labour intesive, so lets not learn how to
>>> use an excavator, but instead develop tools to allow us to organise huge
>>> gangs of navvies with picks and shovels, because that's easier for us
>>> lazy shits than mastering the controls on a dump truck or draglinme
>>> excavator.
>>>
>>> If you cant manage relational databases, you shouldn't be messing with
>>> big data.
>>>
>>>
>> Identify yourself by your real name, doorknob. Maybe then you can put up
>> or shut up.
>>
>> Learn spelling and grammar too - those skills help when you converse
>> with adults.
>>
> So no counter argument, just an ad hominem attack.
>
> You are Jerry Stuckle and I claim my $5.
>
>
>> AHS
>
>
ROFLMAO! This has got to be the stoopidest post you've ever made. And
you've made some pretty stoopid ones!
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex(at)attglobal(dot)net
==================
|
|
|
|
| Re: ORMs comparisons/complaints. [message #184428 is a reply to message #184325] |
Tue, 31 December 2013 13:44 |
Arved Sandstrom
Messages: 9
Registered: December 2013
Karma: 0
|
Junior Member |
|
|
On 12/23/2013 08:25 AM, Silvio wrote:
> 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.
>
> 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.
>
> Silvio
I also find the relational model very useful for modeling data: usually
better than other models. As I noted in another post, ORMs don't
typically distance a programmer that much from relational concepts: they
simply hide some of the mechanics. If you want to routinely use JDBC and
manually construct objects, feel free - I like having libraries doing
some of the heavy lifting.
The last sentence of your last para is remarkable. I'd be interested to
know why an object (a class instance for class-based OO) is a poor
representation of data in a RDBMS. You might as well state that a C
struct or a Haskell data type is unsuitable for that purpose.
If I want to access structured data in an RDBMS, and I am writing in an
OO language (not an uncommon requirement these days), I think I'll use a
semblance of an ORM. I'm reluctant to write assembly language to
manipulate data...not in 2013.
If you had mainly negative experiences with ORMs, Silvio, and I'll take
your word for it, then perhaps your colleagues were inept or incompetent
or lazy. I've experienced the same problems you described, many times:
come to find out that the performance problems were human and needed to
be fired.
AHS
--
When a true genius appears, you can know him by this sign:
that all the dunces are in a confederacy against him.
-- Jonathan Swift
|
|
|
|
| Re: ORMs comparisons/complaints. [message #184429 is a reply to message #184311] |
Tue, 31 December 2013 16:52 |
jebblue
Messages: 2
Registered: December 2013
Karma: 0
|
Junior Member |
|
|
On Sun, 22 Dec 2013 11:05:34 -0800, Daniel Pitts wrote:
> I find that I often stretch systems to there
> limits
It should be their not there.
ORM's are great to get something fairly simple of the ground
fairly fast. From then on any meaningful feature updates
that requires work in the data layer makes using an ORM
a real PITA.
Things like, slow performance, hassles when trying to relate
data between tables, trying to sort out what I want the
SQL to do then all the time it takes to sort out all the
ORM annotations and code and test to satisfy the ORM makes
using the ORM a maintenance headache.
It's a slower coding startup to use straight JDBC but over
time maintenance time and difficulty are linear conststant
with using straight JDBC. Performance is always at a
maximum too.
So when I can, I avoid ORMs completely.
|
|
|
|
| Re: ORMs comparisons/complaints. [message #184431 is a reply to message #184429] |
Tue, 31 December 2013 19:50 |
Evan Platt
Messages: 124
Registered: November 2010
Karma: 0
|
Senior Member |
|
|
On Tue, 31 Dec 2013 10:52:46 -0600, jebblue <n(at)n(dot)nnn> wrote:
> On Sun, 22 Dec 2013 11:05:34 -0800, Daniel Pitts wrote:
>
>> I find that I often stretch systems to there
>> limits
>
> It should be their not there.
>
> ORM's are great to get something fairly simple of the ground
It should be off not of.
> fairly fast. From then on any meaningful feature updates
There should be a comma after on.
> that requires work in the data layer makes using an ORM
> a real PITA.
>
> Things like, slow performance, hassles when trying to relate
There should be no comma after like.
> data between tables, trying to sort out what I want the
> SQL to do then all the time it takes to sort out all the
> ORM annotations and code and test to satisfy the ORM makes
> using the ORM a maintenance headache.
My head hurts reading that run on sentence.
> It's a slower coding startup to use straight JDBC but over
> time maintenance time and difficulty are linear conststant
> with using straight JDBC. Performance is always at a
> maximum too.
>
> So when I can, I avoid ORMs completely.
If you're going to nitpick someone's spelling / grammar, make sure
your post is in order :)
--
To reply via e-mail, remove The Obvious and .invalid from my e-mail address.
|
|
|
|
| Re: ORMs comparisons/complaints. [message #184434 is a reply to message #184429] |
Tue, 31 December 2013 21:54 |
Arved Sandstrom
Messages: 9
Registered: December 2013
Karma: 0
|
Junior Member |
|
|
On 12/31/2013 12:52 PM, jebblue wrote:
> On Sun, 22 Dec 2013 11:05:34 -0800, Daniel Pitts wrote:
>
>> I find that I often stretch systems to there
>> limits
>
> It should be their not there.
>
> ORM's are great to get something fairly simple of the ground
> fairly fast. From then on any meaningful feature updates
> that requires work in the data layer makes using an ORM
> a real PITA.
>
> Things like, slow performance, hassles when trying to relate
> data between tables, trying to sort out what I want the
> SQL to do then all the time it takes to sort out all the
> ORM annotations and code and test to satisfy the ORM makes
> using the ORM a maintenance headache.
>
> It's a slower coding startup to use straight JDBC but over
> time maintenance time and difficulty are linear conststant
> with using straight JDBC. Performance is always at a
> maximum too.
>
> So when I can, I avoid ORMs completely.
>
Have you worked in the programming industry for more than say 5 years?
No point you made actually made much sense. I must admit, I've heard a
few guys just 3 years out of uni who style themselves as technical
architects or senior consultants who opine like this.
Your observations wrt JDBC vs use of an ORM are not borne out by
experience. A fair few knowledgeable people have decided that Java ORMs
make sense: I happen to believe that they are correct - ORMs are
complex, and JDBC is more complex, and not very many coders are truly
adept at SQL.
And "performance is always at a maximum"? JDBC versus ORMs? How so? Just
about 99 percent of the people who write Java ORMs are intimately
familiar with JDBC and SQL - I happen to know a few of them. I
respectfully suggest that if you're having performance problems or can't
solve relational calculus, it's not an ORM problem.
AHS
--
When a true genius appears, you can know him by this sign:
that all the dunces are in a confederacy against him.
-- Jonathan Swift
|
|
|
|
| Re: ORMs comparisons/complaints. [message #184441 is a reply to message #184434] |
Wed, 01 January 2014 01:33 |
jebblue
Messages: 2
Registered: December 2013
Karma: 0
|
Junior Member |
|
|
On Tue, 31 Dec 2013 17:54:12 -0400, Arved Sandstrom wrote:
> On 12/31/2013 12:52 PM, jebblue wrote:
>> On Sun, 22 Dec 2013 11:05:34 -0800, Daniel Pitts wrote:
>>
>>> I find that I often stretch systems to there
>>> limits
>>
>> It should be their not there.
>>
>> ORM's are great to get something fairly simple of the ground
>> fairly fast. From then on any meaningful feature updates
>> that requires work in the data layer makes using an ORM
>> a real PITA.
>>
>> Things like, slow performance, hassles when trying to relate
>> data between tables, trying to sort out what I want the
>> SQL to do then all the time it takes to sort out all the
>> ORM annotations and code and test to satisfy the ORM makes
>> using the ORM a maintenance headache.
>>
>> It's a slower coding startup to use straight JDBC but over
>> time maintenance time and difficulty are linear conststant
>> with using straight JDBC. Performance is always at a
>> maximum too.
>>
>> So when I can, I avoid ORMs completely.
>>
> Have you worked in the programming industry for more than say 5 years?
20 years, over 30 including Hobbyist
> No point you made actually made much sense. I must admit, I've heard a
> few guys just 3 years out of uni who style themselves as technical
> architects or senior consultants who opine like this.
>
> Your observations wrt JDBC vs use of an ORM are not borne out by
> experience. A fair few knowledgeable people have decided that Java ORMs
> make sense: I happen to believe that they are correct - ORMs are
> complex, and JDBC is more complex, and not very many coders are truly
> adept at SQL.
>
> And "performance is always at a maximum"? JDBC versus ORMs? How so? Just
> about 99 percent of the people who write Java ORMs are intimately
> familiar with JDBC and SQL - I happen to know a few of them. I
> respectfully suggest that if you're having performance problems or can't
> solve relational calculus, it's not an ORM problem.
>
> AHS
|
|
|
|
| Re: ORMs comparisons/complaints. [message #184448 is a reply to message #184426] |
Wed, 01 January 2014 14:20 |
Chris Uppal
Messages: 2
Registered: January 2014
Karma: 0
|
Junior Member |
|
|
The Natural Philosopher wrote:
>> Learn spelling and grammar too - those skills help when you converse
>> with adults.
>>
> So no counter argument, just an ad hominem attack.
>
> You are Jerry Stuckle and I claim my $5.
It certainly wasn't the real Arved.
Faked headers too, from the look of it.
-- chris
|
|
|
|
| Re: ORMs comparisons/complaints. [message #184451 is a reply to message #184429] |
Thu, 02 January 2014 02:46 |
Arne Vajhøj
Messages: 27
Registered: December 2013
Karma: 0
|
Junior Member |
|
|
On 12/31/2013 11:52 AM, jebblue wrote:
> On Sun, 22 Dec 2013 11:05:34 -0800, Daniel Pitts wrote:
>
>> I find that I often stretch systems to there
>> limits
> ORM's are great to get something fairly simple of the ground
> fairly fast. From then on any meaningful feature updates
> that requires work in the data layer makes using an ORM
> a real PITA.
That sounds weird.
Let us say that you need to add a field.
With an ORM you only need to update:
* one dataclass
* one mapping of data
With plain JDBC you need to change:
* one data class
* N SQL statements
* N places in the Java code
ORM should be a lot simpler.
> Things like, slow performance,
You should execute the same SQL with and without ORM - the
only overhead is the extra processing in the ORM, which
should be insignificant compared to actually getting the
data from the database.
> hassles when trying to relate
> data between tables,
That is a standard feature in all modern/common ORM's.
> trying to sort out what I want the
> SQL to do
With an ORM you would typical not use SQL.
> then all the time it takes to sort out all the
> ORM annotations and code and test to satisfy the ORM makes
> using the ORM a maintenance headache.
It is fewer changes than plain JDBC.
Arne
|
|
|
|
| Re: ORMs comparisons/complaints. [message #184452 is a reply to message #184413] |
Thu, 02 January 2014 02:54 |
Arne Vajhøj
Messages: 27
Registered: December 2013
Karma: 0
|
Junior Member |
|
|
On 12/30/2013 4:36 PM, Arved Sandstrom wrote:
> I'll say this: Java language limitations have hurt Java ORMs, and it's
> not the fault of the ORM developers: I know a few of them. The JPA
> Criteria API is a sign of the apocalypse. It's unfortunately informed by
> folks who are both struggling with Java limitations and have experience
> with native implementations. C# LINQ and Scala Squeryl are conceptually
> light years ahead of Java ORMs.
Much cleaner syntax.
But I am not convinced that the syntax is sufficient important
to translate that into "light years ahead".
Arne
|
|
|
|
| Re: ORMs comparisons/complaints. [message #184453 is a reply to message #184416] |
Thu, 02 January 2014 02:57 |
Arne Vajhøj
Messages: 27
Registered: December 2013
Karma: 0
|
Junior Member |
|
|
On 12/30/2013 5:13 PM, The Natural Philosopher wrote:
> If you cant manage relational databases, you shouldn't be messing with
> big data.
Why not?
Hint: relational databases are not that common for big data.
Arne
|
|
|
|
| Re: ORMs comparisons/complaints. [message #184454 is a reply to message #184448] |
Thu, 02 January 2014 03:05 |
Arne Vajhøj
Messages: 27
Registered: December 2013
Karma: 0
|
Junior Member |
|
|
On 1/1/2014 9:20 AM, Chris Uppal wrote:
> The Natural Philosopher wrote:
>
>>> Learn spelling and grammar too - those skills help when you converse
>>> with adults.
>>>
>> So no counter argument, just an ad hominem attack.
>>
>> You are Jerry Stuckle and I claim my $5.
>
> It certainly wasn't the real Arved.
>
> Faked headers too, from the look of it.
It did not even show up at the NNTP server I use.
I can only see it via Google.
Arne
|
|
|
|
| Re: ORMs comparisons/complaints. [message #184455 is a reply to message #184400] |
Thu, 02 January 2014 03:19 |
Arne Vajhøj
Messages: 27
Registered: December 2013
Karma: 0
|
Junior Member |
|
|
On 12/30/2013 8:38 AM, Silvio wrote:
> On 12/30/2013 05:27 AM, Arne Vajhøj wrote:
>> 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%.
>
> ORMs are good at what they where invented for: serializing an object and
> resurrecting it at a later point in time.
Storing objects in a relational database via ORM is very different
from serialization (for non-trivial usage).
A serialization stores everything in a sequential stream of data.
Storing objects in a relational database via ORM store the stuff
not already stored in different tables.
Using a document store have some similarities with serialization.
> 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.
No.
It requires the ability to save and load data.
> 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.
That is how persistence works. The data are on disk and when a program
needs them they are read from disk to memory.
> 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.
But that is not in any way ORM specific.
Plain JDBC will have the same potential issues with caching.
> 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.
????
Joins is a core feature of an 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.
Aggregate functions are not very ORM'ish.
But if they are used much in the transactional work that ORM
is intended, then something is wrong in the first place.
> 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.
????
Joins is a core feature of ORM.
And common Java ORM's like JPA implemntations and Hibernate does
aggregate functions exactly like SQL in JPQL and HQL respectively.
I wonder what kind of "experts" you got.
Arne
|
|
|
|
| Re: ORMs comparisons/complaints. [message #184456 is a reply to message #184402] |
Thu, 02 January 2014 03:23 |
Arne Vajhøj
Messages: 27
Registered: December 2013
Karma: 0
|
Junior Member |
|
|
On 12/30/2013 12:36 PM, Daniel Pitts wrote:
> 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.
Plain JDBC code can be written rather portable as well *within* the
area where ORM actually makes sense, so I agree that portability
is not the big argument for ORM.
To me the advantage of using an ORM is simply all the code you
don't have to write.
Regarding getting away from the relational database, then note
that common Java ORM's like JPA implementations and Hibernate
actually allows you to use SQL queries. It is not strongly typed,
but the capability is there.
Arne
|
|
|
|
| Re: ORMs comparisons/complaints. [message #184457 is a reply to message #184454] |
Thu, 02 January 2014 03:48 |
Qu0ll
Messages: 15
Registered: December 2013
Karma: 0
|
Junior Member |
|
|
"Arne Vajhøj" wrote in message
news:52c4d76a$0$303$14726298(at)news(dot)sunsite(dot)dk...
>> It certainly wasn't the real Arved.
>>
>> Faked headers too, from the look of it.
>
> I t did not even show up at the NNTP server I use.
>
> I can only see it via Google.
No guessing required as to who the actual poster was...
--
And loving it,
-Qu0ll (Rare, not extinct)
_________________________________________________
Qu0llSixFour(at)gmail(dot)com
[Replace the "SixFour" with numbers to email me]
|
|
|
|
| Re: ORMs comparisons/complaints. [message #184459 is a reply to message #184453] |
Thu, 02 January 2014 08:04 |
Arved Sandstrom
Messages: 9
Registered: December 2013
Karma: 0
|
Junior Member |
|
|
On 01/01/2014 10:57 PM, Arne Vajhøj wrote:
> On 12/30/2013 5:13 PM, The Natural Philosopher wrote:
>> If you cant manage relational databases, you shouldn't be messing with
>> big data.
>
> Why not?
>
> Hint: relational databases are not that common for big data.
>
> Arne
>
Arne, only because we are going through a phase of people trying to
establish reputations and do some NIH. It's been sexy to refer to shards
and documents and map-reduce and semi-structured data: fact is that for
a number of years we've had quite a few people wasting their time
describing structured data as non-structured data.
By the way, my man, my youngest uncle was also called Arne. Happy NY.
AHS
--
When a true genius appears, you can know him by this sign:
that all the dunces are in a confederacy against him.
-- Jonathan Swift
|
|
|
|
| Re: ORMs comparisons/complaints. [message #184460 is a reply to message #184452] |
Thu, 02 January 2014 08:09 |
Arved Sandstrom
Messages: 9
Registered: December 2013
Karma: 0
|
Junior Member |
|
|
On 01/01/2014 10:54 PM, Arne Vajhøj wrote:
> On 12/30/2013 4:36 PM, Arved Sandstrom wrote:
>> I'll say this: Java language limitations have hurt Java ORMs, and it's
>> not the fault of the ORM developers: I know a few of them. The JPA
>> Criteria API is a sign of the apocalypse. It's unfortunately informed by
>> folks who are both struggling with Java limitations and have experience
>> with native implementations. C# LINQ and Scala Squeryl are conceptually
>> light years ahead of Java ORMs.
>
> Much cleaner syntax.
>
> But I am not convinced that the syntax is sufficient important
> to translate that into "light years ahead".
>
> Arne
>
We can agree to disagree, Arne. I think ideas like C# LINQ and Scala
Squeryl are far in advance of Java.
I was able to write a Scala DSL a few years ago that would not have been
possible in Java. Similarly, C# - I think you'd have to admit - is quite
far ahead of Java.
AHS
--
When a true genius appears, you can know him by this sign:
that all the dunces are in a confederacy against him.
-- Jonathan Swift
|
|
|
|
| Re: ORMs comparisons/complaints. [message #184461 is a reply to message #184451] |
Thu, 02 January 2014 08:34 |
Gordon Levi
Messages: 2
Registered: January 2014
Karma: 0
|
Junior Member |
|
|
Arne Vajhøj <arne(at)vajhoej(dot)dk> wrote:
> Let us say that you need to add a field.
>
> With an ORM you only need to update:
> * one dataclass
> * one mapping of data
>
> With plain JDBC you need to change:
> * one data class
> * N SQL statements
> * N places in the Java code
I don't understand this so I fear I must be doing something wrong in
my Java programs. If someone wants to add a field in a database why do
I have to alter anything in my program other than adding, for example,
getString(String columnLabel) if I want to actually use the new field
at that point in the program.
|
|
|
|
| Re: ORMs comparisons/complaints. [message #184463 is a reply to message #184455] |
Thu, 02 January 2014 11:36 |
Silvio
Messages: 5
Registered: December 2013
Karma: 0
|
Junior Member |
|
|
On 01/02/2014 04:19 AM, Arne Vajhøj wrote:
> On 12/30/2013 8:38 AM, Silvio wrote:
>> On 12/30/2013 05:27 AM, Arne Vajhøj wrote:
>>> 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%.
>>
>> ORMs are good at what they where invented for: serializing an object and
>> resurrecting it at a later point in time.
>
> Storing objects in a relational database via ORM is very different
> from serialization (for non-trivial usage).
>
> A serialization stores everything in a sequential stream of data.
>
> Storing objects in a relational database via ORM store the stuff
> not already stored in different tables.
>
> Using a document store have some similarities with serialization.
>
I meant serialization in the more general sense. I am not talking about
Object(In/Out)putStream but about saving the exact state of an instance
to some addressable storage with the main purpose of restoring its state
later.
>> 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.
>
> No.
>
> It requires the ability to save and load data.
>
No, not data but instances. My point is that these are fundamentally
different.
>> 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.
>
> That is how persistence works. The data are on disk and when a program
> needs them they are read from disk to memory.
>
>> 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.
>
> But that is not in any way ORM specific.
>
> Plain JDBC will have the same potential issues with caching.
>
In theory the ORM approach does not need more caching than a RDBMS
driven approach. In practice this is not the case. The number of cases
where caching outside of the RDBMS is actually needed is very limited
and I rarely use any form of data caching.
Without exception all the ORM systems I worked on relied heavily on
caching or the would not be practically usable.
>> 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.
>
> ????
>
> Joins is a core feature of an ORM.
>
You can do joins easily but that is not the big problem. The core
problem is that joins create new views on the underlying data that do
not match with the entity classes that match its underlying tables. To
represent the data from a join properly you would need a new class and
then you get into one of the biggest culprits with ORM: aliased data and
cache redundancy.
>> 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.
>
> Aggregate functions are not very ORM'ish.
>
> But if they are used much in the transactional work that ORM
> is intended, then something is wrong in the first place.
>
That is just my point. I never encounter any purely transactional
system. That is almost always a part but it is always the easy part.
Also, it's not that ORM tool providers shout from the roofs that you
should only use them for transactional stuff...
>> 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.
>
> ????
>
> Joins is a core feature of ORM.
>
> And common Java ORM's like JPA implemntations and Hibernate does
> aggregate functions exactly like SQL in JPQL and HQL respectively.
>
> I wonder what kind of "experts" you got.
>
> Arne
>
Yes, they got all the stuff working the first time with joins and
aggregates like you say. But after some time they got into trouble
because aliased data caused the systems to show faulty counts and totals
etc. and from there on it went down-hill. On more than one system they
had to forcefully flush the cache at specific moments to get the right
results for subsequent reporting. Which then did not work very promptly,
to put it mildly.
Most systems I work(ed) on are primarily analytical systems working on
data that comes from surveys, measure devices, order tracking systems
etc. and fetching a record and storing it after manually changing some
attributes is not the common use case. The primary goal is to properly
manage such data at the record level behind the scenes while at the same
time allow thorough analysis of the overall process. Much of this
requires aggregates on joins that have to be built dynamically because
the user can specify exactly what he needs via a UI, akin to an OLAP
system.
I admit that this is not a good match for ORM but in these cases that
was hindsight wisdom. When they started they thought ORM was the right
tool. Which does not surprise me since I encounter many people who never
doubt ORM is the way to go with any system.
|
|
|
|
Calendar
Search
Help
Members
Register
Login
Home
]