[Dbix-class] Moose

[Leandro Hermida]

On Sat, Jul 10, 2010 at 8:07 PM, John Napiorkowski <jjn1056 at yahoo.com> wrote:
>
> ----- Original Message ----
>> From: Leandro Hermida <softdev at leandrohermida.com>
>> To: DBIx::Class user and developer list <dbix-class at lists.scsys.co.uk>
>> Sent: Fri, July 9, 2010 4:41:57 AM
>> Subject: [Dbix-class] Moose
>>
>> Hi all,
>>
>> Been an avid DBIx::Class user for a long time and something I've  been
>> looking for on CPAN on and off also for a long time and thought  maybe
>> it would be possible now that Moose has made such an impact and  good
>> OO paradigm programming can be done in Perl... in Java EE (gasp!)  you
>> have such a thing as JPA, where you define in a standard way  classes
>> for your entity/data objects and via object/relational  metadata
>> (annotations in Java) define in these classes the  relationships
>> between the entities and any ORM mapping particulars that  the
>> underlying ORM engine should use. The underlying ORM  transparently
>> handles how the relational schema should map for the particular  RDBMS
>> being used and ones does queries in an object-centric way and also  the
>> ORM handles how this maps to the appropriate SQL for the schema,  you
>> get the idea.
>>
>> I always thought JPA was a nice concept since if one  is doing OO
>> programming this is the way one should be thinking about their  data
>> model. Now there are object persistence frameworks in Perl like  e.g.
>> KiokuDB but they don't do real ORM (unless I didn't read  something
>> right) and one might argue why do I need ORM and not just persist  the
>> objects in a store? There are many common reasons where ORM  is
>> required, off the top of my head the fact that commonly other  systems
>> will need to interact with your database and can only work with  SQL
>> and therefore need to see a proper relational data model. There  are
>> also other frameworks like Fey::ORM and Tangram but these  seem
>> dangerous to use in any serious project because they have the  common
>> CPAN problem that they don't have a big enough developer  community
>> behind it and/or aren't even really maintained or developed  further
>> anymore (no offense to the people behind these libraries at all,  they
>> are probably very nice frameworks, but you can understand how scary  it
>> can be to use something like this at work in a big project)
>
> I used to feel the same way about Fey, but I know several very smart people are
> using it for production level work, so to a degree I feel more comfortable with
> it.
>

Good point, but still a hard sell to developer colleagues who already
don't like how CPAN works and have gotten burnt in the past.  With
DBIx::Class there seems to be a lot of momentum, people, etc. behind
the project and it has become a standard module which is really great!

>
>>
>> Anyway  sorry for the babble, is it possible with Moose and using
>> DBIx::Class as the  underlying ORM engine to create something a la JPA?
>> Or will it be possible  once DBIx::Class 0.09 series comes out and is
>> more Moose-based?  I've  looked through the archives and on googling
>> and haven't really seen any clear  approaches.
>
> I know mst has been quietly working on a DBIC2 thing, which I am not certain
> will fit your JPA like bill, but given the presentations and talks I've heard it
> might be something even more interesting.
>

This sound really exciting, I think I saw on of his talks too on the
web regarding the future of DBIC and there were a lot of cool ideas!

> You also might want to look at KiokuDB, which integrates with DBIC and gives you
> some ability to just declare stuff in Moose and get persistance, although its
> not intended to be an ORM.  It does have a very active development community
> around it.  You should take a look.
>

I had a look at KiokuDB, its a very nice project and suitable for
certain needs, but it doesn't do ORM. In many software development
projects particularly business-related you really the database to be a
relational implementation of your entity object model because you have
other systems, software and programming languages that will be
interacting with the database.

>>
>> best,
>> Leandro
>>