[Dbix-class] Moose

Peter Rabbitson rabbit+dbic at rabbit.us
Mon Jul 19 22:31:14 GMT 2010


On Mon, Jul 19, 2010 at 11:20:15AM -0700, Darren Duncan wrote:
> Peter Rabbitson wrote:
>> On Sun, Jul 18, 2010 at 02:40:47PM +0200, Leandro Hermida wrote:
>>> very good points and makes a lot of sense.  If I can ask a more general
>>> question then, why do ORMs exist in the first place and why are they so
>>> popular vs using a object persistence mechanism?  There must be some serious
>>> advantage to using them.
>>
>> Because there yet does not exist a persistent object store, that can be
>> asked to fetch "all objects which have related objects whose attribute X
>> is Y", and which will do so by *transparrently* using native SQL methods
>> (namely GROUP BY over a joined resultset). Matt Trout is working on the
>> foundation of just such a "mapper", but this is a very very hard problem
>> to get right, so progress is slow.
>
> What are you referring to exactly?  "SQL-Abstract-2"?  Which last I 
> looked hadn't had any version control activity in a year?  Or something 
> else?  Url?
>
> Separately ...
>
> Following up my prior post, referencing a talk given yesterday,  
> http://thebuild.com/blog/2010/07/18/orms-and-their-discontents-2/ , one 
> of the interesting points raised that I recall is that ORMs typically 
> start simple and address the desire of an application programmer to just 
> save an object to disk, and they don't want to know SQL.

Which one can argue does not apply to DBIC, and *definitely* does not apply
to Data::Store. D::S is about bringing a store-agnostic (losely) related data
query mechanism built *entirely* on top of modern perl. Note: not
RDBMS-agnostic, but store agnostic. D::S is not about "ooh I want to persist
these objects" - we have KiokuDB for this.

> And then the ORM gets more complicated as actual business requirements 
> set in, such as "okay, great, now I need a report of customers of who 
> have paid at least 50% of their balances", and then the ORM's API 
> eventually just becomes a proprietary alternate syntax of SQL, in order 
> to meet the user's needs that they would otherwise have written in SQL, 
> and so the users haven't really avoided having to know something about 
> SQL after all.

Can't comment on the talk as I haven't seen it, but I find the slides...
disturbing. They seem to represent a complete utter failure of grasping what
modern ORMs can and can not do (and what they strive to achieve). I will not
go any further than this, but I have a lot to say if asked to elaborate :)

Cheers



More information about the DBIx-Class mailing list