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/ ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ Ledger-smb-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/ledger-smb-devel
