Re: Language wars...

["Joshua D. Drake" <..hidden..>]

Ed W wrote:
> Hi
> 
>> We are moving to a 90% SP model. Meaning that all data logic is going to
>> happen in stored procedures. ORMs, at least every one that I have seen
>> have no easy way to deal with using SPs.
>>   
> 
> Well, this is the only reason I keen harking on about the whole thing - 
> I believe that you are incorrect and that in fact most ORM's have no 
> problem at all with you writing your own SQL or using SPs

Hibernate
ActiveRecord
DJango
SQLObject
SQLAlchemy

All, suffer from it.

> 
> Rails for example is a bit tied down to using a database, but for 
> example Catalyst is very flexible in this regard.  As a simple example 
> check CPAN for Catalyt::Model and one of the first few search entries is 
> Catalyst::Model::You-Tube
> http://search.cpan.org/~jshirley/Catalyst-Model-YouTube-0.12/lib/Catalyst/Model/YouTube.pm
> 
> If this doesn't make you strongly suspect that badly written SQL is NOT 
> required for a successful ORM then I'm really not sure what will!
> 
> Scanning through the list we can pick out some interesting other model's 
> such as: Catalyst::Model::JabberRPC , Catalyst::Model::XML::Feed  (cool 
> parse XML output from another source!), Catalyst::Model::EmailStore  
> (wierd!), Catalyst::Model::SVN, Catalyst::Model::LDAP
> 
> See what I mean?

All of which is just wrappers against already available perl modules so
what are we gaining?

> All I am saying is don't overlook frameworks such as Catalyst if you 
> have never used one before.  They really do bring a *huge* bunch of 
> functionality to your application for free.  Catalyst for example has 
> this rather neat mini-webserver built in for development - you can't 
> imagine how useful I find this same feature in Rails that I can just 

Although I have not worked with Catalyst I have reviewed it quite a bit
because I was considering it against other options.

I was walking through the tutorial and everything looked fairly
reasonable until:

 # load from multiple namespaces.
    __PACKAGE__->load_classes({
        MyAppDB => [qw/Book BookAuthor Author/]
    });

    1;

# has_many():
    #   args:
    #     1) Name of relationship, DBIC will create accessor with this name
    #     2) Name of the model class referenced by this relationship
    #     3) Column name in *foreign* table
    __PACKAGE__->has_many(book_authors => 'MyAppDB::BookAuthor', 'book_id');


Which is ugly, beyond ugly and I am not interested any longer.

I fully understand your theory on frameworks. I use Django for a lot of
work. That being said... Frameworks are great when you need a kitchen
sink, fridge, floors and cabinets.

We just need the fridge.


Sincerely,

Joshua D. Drake





-- 

      === The PostgreSQL Company: Command Prompt, Inc. ===
Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240
Providing the most comprehensive  PostgreSQL solutions since 1997
             http://www.commandprompt.com/

Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate
PostgreSQL Replication: http://www.commandprompt.com/products/