Perl versus ORM

[Rainer Weikusat]

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.

 

[Michael Vilain]

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.

 

[Peter Makholm]

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

 

[Rainer Weikusat]

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.

Hmm ... I just spent 02:15h of my life working out how exactly the
-XX:OnOutOfMemoryError (Oracle/ Sun) JVM command-line option can be
used in a sensible way in our environment so that my "Java colleagues"
don't get 3am phonecalls from Japanese customers anymore because the
JVM has 'out-of-memoried' itself into a stupor and needs a kick in the
underbelly (aka application restart) for things to start working
again ...

You won't get Perl to change by posting this to perl news group.

I wasn't advocating for Perl to change, I think it is 'mostly fine'
the way it is and specifically, I consider the absence of a
language-mandated way for representing objects a feature: I'm
presently working on adding sensible support for hostname-using
firewall rules to a 'configuration engine' written in Perl. As part of
that, I have added a hostname database class (derived of an existing
database class) supposed to manage 'hostname objects'. These are
supposed to contain the actual hostnames, to provide access to the
corresponding IP address and to store some meta-information necessary
for manageing DNS lookups and integration with the other parts of the
program. Specifically, this is

- the hostname, a string

- a reference to an array of IP addresses

- a reference to a timer object used the schedule DNS queries
depending on the result of the last query (either requery
when the TTL of the present result set was exceeded or retry
the query with a longer or shorter 'period' in order to deal
with temporary or (semi-)permanent name resolution errors)

- a flag which indicates if the IP address set changed since
'some other part of the program' used it for the last time

While the configuration engine is usually supposed to have a
connection to a management database server, it also needs to function
as good as it can when this server is presently unreachable. Because
of this, the contents of all databases maintained by it are serialized
to some set of files and read from these files during startup. This is
all done by existing code. In case of the hostname database, none of
the data members except the hostname itself should be written to disk.

At the implementation level, this works such that the hostname object
is a reference to a scalar storing the name itself and all other
instance variables are kept in an array reference pointed to by a hash
indexed by the refaddr (Scalar::Util::refaddr) of the object.

The idea to do stuff like that will probably cause some people,
especially, people with an unhealthy exposure to less capable
languages like Java or C++, to go into "Repent, sinner, or be burnt like
a steak!"-mode but I found the fact that the representation of Perl
objects can vary if need be frequently useful in other situations in
the past. It just occured to me that 'using an ORM' in Perl should
usually necessarily imply 'also using the YARFPOO piggy-backing on
it', ie, one not only loses easy access to a lot of database features
supposed to make one's life easier but access to certain Perl features
as well.

 

[Peter Makholm]

I wasn't advocating for Perl to change, I think it is 'mostly fine'
the way it is and specifically, I consider the absence of a
language-mandated way for representing objects a feature:

I do not think that any skilled programmer think that persintency is a
required feature for all kinds of object. Especially not state that are
just cached information like in you description.

I also belive that Java programmers would be less likely to object to
using strong encapsulation to enforce this design decision than Perl
programmers. As I see it using inside-out objects to enforce
encapsulation in Perl was a fad that has waned.

//Makholm