[32531] in Perl-Users-Digest
Perl-Users Digest, Issue: 3796 Volume: 11
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Mon Oct 15 21:09:17 2012
Date: Mon, 15 Oct 2012 18:09:04 -0700 (PDT)
From: Perl-Users Digest <Perl-Users-Request@ruby.OCE.ORST.EDU>
To: Perl-Users@ruby.OCE.ORST.EDU (Perl-Users Digest)
Perl-Users Digest Mon, 15 Oct 2012 Volume: 11 Number: 3796
Today's topics:
Re: Perl versus ORM <vilain@NOspamcop.net>
Re: Perl versus ORM <peter@makholm.net>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Sun, 14 Oct 2012 20:33:56 -0700
From: Michael Vilain <vilain@NOspamcop.net>
Subject: Re: Perl versus ORM
Message-Id: <vilain-A74322.20335514102012@news.individual.net>
In article <87lif825gu.fsf@sapphire.mobileactivedefense.com>,
Rainer Weikusat <rweikusat@mssgmbh.com> wrote:
> Considering that the purpose of an object-relational mapping layer is
> to 'persist' some set of objects which are instances of some set of
> classes by autogenerating the SQL statements necessary to store the
> data contained in this objects instances in some set of tables managed
> by a RDBMS and to recreate the equivalent object instances from the
> data in the database, the concept seem singularly ill-suited to Perl
> because there is no such thing as 'the Perl object representation' --
> an object instances is a reference blessed into a package defining
> some set of methods: The reference can be a reference to anything Perl
> can create references to and how precisely 'the reference' is linked
> to the actual instance data is left to the implementation of the
> class.
Look at the various database classes in Java. I have friends that look
down their nose at my perl coding and tell me Java is capable of doing
so many more wonderful things.
You won't get Perl to change by posting this to perl news group. Most
likely you'll get yourself a colostomy and have to change your own bag
for the rest of your life.
--
DeeDee, don't press that button! DeeDee! NO! Dee...
[I filter all Goggle Groups posts, so any reply may be automatically ignored]
------------------------------
Date: Mon, 15 Oct 2012 09:56:18 +0200
From: Peter Makholm <peter@makholm.net>
Subject: Re: Perl versus ORM
Message-Id: <87hapwyxr1.fsf@vps1.hacking.dk>
Rainer Weikusat <rweikusat@mssgmbh.com> writes:
> Considering that the purpose of an object-relational mapping layer is
> to 'persist' some set of objects which are instances of some set of
> classes by autogenerating the SQL statements necessary to store the
> data contained in this objects instances in some set of tables managed
> by a RDBMS and to recreate the equivalent object instances from the
> data in the database, the concept seem singularly ill-suited to Perl
> because there is no such thing as 'the Perl object representation' --
While it is true there there are no '*the* Perl object representation',
most classes adheres to '*a* object representation'. So while a
universal general-purpose ORM is not viable, each object framework can
provide ORM capabilities.
So even though we can't have 'the Perl ORM' we might have 'the standard
Moose ORM'. But in reality it often happens the other way around that
you choose you favorite Perl ORM framework, which then provides the
object representation.
//Makholm
------------------------------
Date: 6 Apr 2001 21:33:47 GMT (Last modified)
From: Perl-Users-Request@ruby.oce.orst.edu (Perl-Users-Digest Admin)
Subject: Digest Administrivia (Last modified: 6 Apr 01)
Message-Id: <null>
Administrivia:
To submit articles to comp.lang.perl.announce, send your article to
clpa@perl.com.
Back issues are available via anonymous ftp from
ftp://cil-www.oce.orst.edu/pub/perl/old-digests.
#For other requests pertaining to the digest, send mail to
#perl-users-request@ruby.oce.orst.edu. Do not waste your time or mine
#sending perl questions to the -request address, I don't have time to
#answer them even if I did know the answer.
------------------------------
End of Perl-Users Digest V11 Issue 3796
***************************************
