Re: [Catalyst] Alternatives to DBIx?
Lyle ha scritto: Kiffin Gish wrote: I'd say that rather than spending time studying SQL::DB, which I found complicated and hard to tackle, you might as well invest the same time and energy anyway in figuring out DBIx::Class. TBH if I really found the need for the DB to match up to objects, then I'd use an Object Database, not a Relational one. The only real argument for using a relational one instead, in that situation, is the performance benefits. When you want top performance from a relational database, you won't be using an ORM anyway. But the question is: do you need raw dbi performance all over the place ? Just as you can write some critical functions in assembly and wrap them up in a C function or C++ class method, you can use an ORM to speed up development and have easier code maintenance, and use dbi+raw sql where you find a performance bottleneck. Also, as someone has mentioned earlier in this thread, DBIC requires a well-designed db schema, so in some way it prevents bad design decisions at the raw-sql level, thus helping to acheive good performance right from the start. Lyle ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/ Just my 2 (euro) cents. -- Marcello Romani ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
RE: [Catalyst] Alternatives to DBIx?
-Message d'origine- De : John Karr [mailto:brain...@brainbuz.org] Envoyé : samedi, 17. avril 2010 07:02 À : 'The elegant MVC web framework' Objet : [Catalyst] Alternatives to DBIx? The alternatives I've been able to discover are DBI and RoseDB. Is there any case (given why I've already stated I dislike DBIx) for RoseDB, and are there any other alternatives that work well with Catalyst that I have not found? One alternative that has not been mentioned so far is DBIx::DataModel. See http://search.cpan.org/~dami/DBIx-DataModel-1.24/lib/DBIx/DataModel.pm for SYNOPSIS, http://search.cpan.org/~dami/DBIx-DataModel-1.24/lib/DBIx/DataModel/Doc/Design.pod for design principles and some words about comparison to other ORMs, and http://search.cpan.org/~dami/DBIx-DataModel-1.24/lib/DBIx/DataModel/Doc/Reference.pod for complete reference. Enjoy, Laurent Dami ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Alternatives to DBIx?
kevin montuori wrote: In my experience (two or so years with DBIC/Catalyst and many, many more with sundry DBI hacks) DBIC code has proven trivial to maintain and augment. Furthermore, it's relatively easy to find programmers who are familiar with it and can be brought up to speed quickly. Your situation might be different; for me the maintenance is as important as the development. This. At $work we adopted DBIC around 3 years ago when we switched to Catalyst. Since then, whenever we've brought new people onto the team I've had plenty of discussions with them about how much DBIC gets in the way and they would be able to get stuff done quicker if we just allowed them to write the SQL queries. Eventually given enough experience with what we do, everybody comes around to seeing how much better things are with DBIC - especially when it comes to adding new features into the existing code base. I would say that DBIC actually becomes most useful when you stop thinking about SQL and start thinking in terms of the data that you actually need. Instead of trying to convert SQL to code, you just code and can be more productive. Carl ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Alternatives to DBIx?
kevin montuori wrote: In my experience (two or so years with DBIC/Catalyst and many, many more with sundry DBI hacks) DBIC code has proven trivial to maintain and augment. Furthermore, it's relatively easy to find programmers Exactly. Also I have an authz library that works against Oracle, Mysql and SQLite (and if I tried it, undoubtedly Postgresql too) without any trick code. DBIx::Class ++ Regards, Peter http://perl.dragonstaff.co.uk ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Alternatives to DBIx?
On 19 April 2010 12:34, Carl Johnstone catal...@fadetoblack.me.uk wrote: kevin montuori wrote: DBIC code has proven trivial to maintain and augment. ...how much better things are with DBIC - especially when it comes to adding new features into the existing code base. Absolutely! When you are doing complicated reporting rollups (multiple joins, subqueries, aggregate functions) that can be arbitrarily tweaked, sorted, paged etc. then modifying with DBIC is often just a case of tweaking a single hash declaration... (Whereas updating a dynamic SQL codegen may well involve an hour of headscratching... Not to mention the other hour of debugging later, because you forgot to add a space or comma that kicks in with some rarely used set of parameters...) osfameron ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Alternatives to DBIx?
On Saturday, April 17, 2010 06:04:58 pm John Karr wrote: In my own analysis the Time and Effort to learn DBIx is greater than the Time wasted writing repetitious DBI code, the time I've already invested on DBIx has shown that there is a better way than DBI, but for me it isn't DBIx. In my own analysis the fact that you still think that there is a thing called DBIx proves that the time and effort you've spent learning _DBIC_ is zero. ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Alternatives to DBIx?
On Sunday, April 18, 2010 12:14:55 am Eden Cardim wrote: On Sat, Apr 17, 2010 at 8:04 PM, John Karr brain...@brainbuz.org wrote: Both Fey and SQLDB are a nativist approach to SQL (much like TT is to html) TT isn't a native approach to html, by far. In fact, it has quite a few things going against it's use to generate html. Besides what jshirley already said, it doesn't produce streamable output and once your documents get complex, it's not very easy to produce nicely indented code with it. For a native approach to html, try HTML::Zoom. Very true. In fact, ignoring the fact that it ships with a couple default plugins that know how to do HTML-compatible string encoding, TT doesn't actually know anything about HTML. It's not actually an HTML tool at all; it's a tool for pasting strings together. It's entirely possible for those strings to be HTML tags, but since TT is agnostic, it's equally good at producing completely mangled, invalid HTML as it is at producing useful HTML (note: not a value judgment, just a simple fact!) If that's what nativist means, and you're looking for a tool that takes a string-schlepping approach to *SQL*, then you need look no further than a hundred thousand shitty PHP apps ;) Andrew ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Alternatives to DBIx?
- Original Message From: John Karr brain...@brainbuz.org The alternatives I've been able to discover are DBI and RoseDB. Is there any case (given why I've already stated I dislike DBIx) for RoseDB, and are there any other alternatives that work well with Catalyst that I have not found? Given what you've described, perhaps you want to take a look at Fey::SQL: http://search.cpan.org/perldoc?Fey::SQL The related Fey::ORM can be used with Catalyst: http://search.cpan.org/perldoc?Fey::ORM::Manual::Intro Cheers, Ovid -- Buy the book - http://www.oreilly.com/catalog/perlhks/ Tech blog - http://blogs.perl.org/users/ovid/ Twitter - http://twitter.com/OvidPerl Official Perl 6 Wiki - http://www.perlfoundation.org/perl6 ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Alternatives to DBIx?
Personally I think DBIx::Class is the biggest load of crock out there. It's much slower, awkward to use, time consuming to learn, and as soon as you try to do some complicated queries you'll end up dropping it anyway. ORMs simply cannot work in the long run:- http://www.codinghorror.com/blog/2006/06/object-relational-mapping-is-the-vietnam-of-computer-science.html I found SQL::DB recently, which looks interesting to me, but haven't had chance to work with it yet. It might be what you are looking for. Lyle John Karr wrote: I'm still learning Catalyst and find that I don't like DBIx. As a counter example I love Template Toolkit, for exactly the same reason I hate DBIx. With TT html is in html, while DBIx seperates the database from SQL, if I were capable of writing an ORM (which I am not) it would be much more like Template Toolkit. Also I'm primarily a sysadmin working on some volunteer programming projects while out of work, so even though it might well be worth coming to terms with DBIx if I did more development, crawling through DBI seems a more efficient way for me to get working code written. The alternatives I've been able to discover are DBI and RoseDB. Is there any case (given why I've already stated I dislike DBIx) for RoseDB, and are there any other alternatives that work well with Catalyst that I have not found? ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/ ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
RE: [Catalyst] Alternatives to DBIx?
Thanks Lyle and Ovid for your responses, both SQL::DB and Fey::SQL look like saner approaches, and I will take them both for a test drive. I also liked the article Lyle referenced. -Original Message- From: Lyle [mailto:webmas...@cosmicperl.com] Sent: Saturday, April 17, 2010 9:36 AM To: The elegant MVC web framework Subject: Re: [Catalyst] Alternatives to DBIx? Personally I think DBIx::Class is the biggest load of crock out there. It's much slower, awkward to use, time consuming to learn, and as soon as you try to do some complicated queries you'll end up dropping it anyway. ORMs simply cannot work in the long run:- http://www.codinghorror.com/blog/2006/06/object-relational-mapping-is-the-vi etnam-of-computer-science.html I found SQL::DB recently, which looks interesting to me, but haven't had chance to work with it yet. It might be what you are looking for. Lyle Ovid Wrote: Given what you've described, perhaps you want to take a look at Fey::SQL: http://search.cpan.org/perldoc?Fey::SQL The related Fey::ORM can be used with Catalyst: http://search.cpan.org/perldoc?Fey::ORM::Manual::Intro John Karr wrote: I'm still learning Catalyst and find that I don't like DBIx. As a counter example I love Template Toolkit, for exactly the same reason I hate DBIx. With TT html is in html, while DBIx seperates the database from SQL, if I were capable of writing an ORM (which I am not) it would be much more like Template Toolkit. Also I'm primarily a sysadmin working on some volunteer programming projects while out of work, so even though it might well be worth coming to terms with DBIx if I did more development, crawling through DBI seems a more efficient way for me to get working code written. The alternatives I've been able to discover are DBI and RoseDB. Is there any case (given why I've already stated I dislike DBIx) for RoseDB, and are there any other alternatives that work well with Catalyst that I have not found? ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/ ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/ ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Alternatives to DBIx?
On Sat, Apr 17, 2010 at 6:35 AM, Lyle webmas...@cosmicperl.com wrote: Personally I think DBIx::Class is the biggest load of crock out there. It's much slower, awkward to use, time consuming to learn, and as soon as you try to do some complicated queries you'll end up dropping it anyway. ORMs simply cannot work in the long run:- http://www.codinghorror.com/blog/2006/06/object-relational-mapping-is-the-vietnam-of-computer-science.html I found SQL::DB recently, which looks interesting to me, but haven't had chance to work with it yet. It might be what you are looking for. Lyle Way to be respectful of the hard work of other people, and the successes they've had. All your points are subjective and some are just wrong. It's much slower than what? Time consuming to learn? How's that? If you already know SQL, sure. If you don't, DBIC is probably much faster. Complicated Queries? Sorry, but I run *massively* complicated reporting queries (using custom result sources, no real objects) and it spits out a series of *very* advanced reports. It wasn't hard, took me about 2 hours to get that up and running. ORMs have their limitation, but to just attack a measurably successful project with baseless FUD is simply disrespectful. ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Alternatives to DBIx?
On Apr 17, 2010, at 7:59 AM, John Karr wrote: Thanks Lyle and Ovid for your responses, both SQL::DB and Fey::SQL look like saner approaches, and I will take them both for a test drive. I also liked the article Lyle referenced. -Original Message- From: Lyle [mailto:webmas...@cosmicperl.com] Sent: Saturday, April 17, 2010 9:36 AM To: The elegant MVC web framework Subject: Re: [Catalyst] Alternatives to DBIx? Personally I think DBIx::Class is the biggest load of crock out there. It's much slower, awkward to use, time consuming to learn, and as soon as you try to do some complicated queries you'll end up dropping it anyway. ORMs simply cannot work in the long run:- http://www.codinghorror.com/blog/2006/06/object-relational-mapping-is-the-vi etnam-of-computer-science.html Just to put it out there -- I think for every dev who has arrived at this conclusion there are more who think DBIx::Class and Rose::DB and friends are wonderful. DBIC does have one caveat that can make it bad a choice: it requires some rigor in your database schema. Broken, bad, goofy DB relationships make DBIC a poor choice because you might have to resort to crazy code to make things work. If your schema is sane, everything, even extremely complicated queries are generally easy (after you get ramped up, it does have a learning curve). Of course you can use straight DBI etc and if it's what you're used to it will be much faster at first. The main issue is that you'll get templates or controllers littered with shims, iterators, raw SQL etc. You could of course start pushing it back into the model yourself but what that'll be doing is slowly reinventing one of the other ORMs but much less well. This is basically every Perl developer has to write his own templating language once to learn why it's such a bad, part 2. You'll have to learn a lot either way. The Stone Soup of rolling it yourself is seductive and seems easier but taken as a whole it is most certainly not. -Ashley ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Alternatives to DBIx?
I'd say that rather than spending time studying SQL::DB, which I found complicated and hard to tackle, you might as well invest the same time and energy anyway in figuring out DBIx::Class. On Sat, 2010-04-17 at 14:35 +0100, Lyle wrote: Personally I think DBIx::Class is the biggest load of crock out there. It's much slower, awkward to use, time consuming to learn, and as soon as you try to do some complicated queries you'll end up dropping it anyway. ORMs simply cannot work in the long run:- http://www.codinghorror.com/blog/2006/06/object-relational-mapping-is-the-vietnam-of-computer-science.html I found SQL::DB recently, which looks interesting to me, but haven't had chance to work with it yet. It might be what you are looking for. Lyle John Karr wrote: I'm still learning Catalyst and find that I don't like DBIx. As a counter example I love Template Toolkit, for exactly the same reason I hate DBIx. With TT html is in html, while DBIx seperates the database from SQL, if I were capable of writing an ORM (which I am not) it would be much more like Template Toolkit. Also I'm primarily a sysadmin working on some volunteer programming projects while out of work, so even though it might well be worth coming to terms with DBIx if I did more development, crawling through DBI seems a more efficient way for me to get working code written. The alternatives I've been able to discover are DBI and RoseDB. Is there any case (given why I've already stated I dislike DBIx) for RoseDB, and are there any other alternatives that work well with Catalyst that I have not found? ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/ ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/ -- Kiffin Gish kiffin.g...@planet.nl Gouda, The Netherlands ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Alternatives to DBIx?
From: Kiffin Gish kiffin.g...@planet.nl I'd say that rather than spending time studying SQL::DB, which I found complicated and hard to tackle, you might as well invest the same time and energy anyway in figuring out DBIx::Class. BTW, is there a comparison among the ORMs in Perl somewhere? It would be interesting and definitely helpful for the ORM newbies. Octavian ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Alternatives to DBIx?
Kiffin Gish wrote: I'd say that rather than spending time studying SQL::DB, which I found complicated and hard to tackle, you might as well invest the same time and energy anyway in figuring out DBIx::Class. TBH if I really found the need for the DB to match up to objects, then I'd use an Object Database, not a Relational one. The only real argument for using a relational one instead, in that situation, is the performance benefits. When you want top performance from a relational database, you won't be using an ORM anyway. Lyle ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
RE: [Catalyst] Alternatives to DBIx?
I think there's a very important difference of approach, much as Template Tool Kit and Template Declare, radically different approaches, that are both far superior to the classic CGI Module. Working in raw DBI is the opposite of the DRY principle which underlies having a framework in the first place, so I am seeking an alternative. Just as Catalyst uses MVC, DBIx chooses ORM, but that paradigm is not the only way to be effective PERL==SQL glue. From the Manpage Fey::SQL looks like what I want: neatly wrapped and sweetened SQL, without the repetition and overhead inherent in working from DBI. I'm going to spend some time working with it and also with SQL::DB, when I have a more educated opinion I will share it. Both Fey and SQLDB are a nativist approach to SQL (much like TT is to html), and I would argue that in keeping the PERL paradigm of many ways to accomplish a task, the choice between a SQL-native DBI wrapper and an ORM wrapper should be up to the individual, the issue seems to be finding a worthy SQL-native wrapper. In my own analysis the Time and Effort to learn DBIx is greater than the Time wasted writing repetitious DBI code, the time I've already invested on DBIx has shown that there is a better way than DBI, but for me it isn't DBIx. -Original Message- From: Octavian Rasnita [mailto:orasn...@gmail.com] Sent: Saturday, April 17, 2010 3:58 PM To: The elegant MVC web framework Subject: Re: [Catalyst] Alternatives to DBIx? From: Kiffin Gish kiffin.g...@planet.nl I'd say that rather than spending time studying SQL::DB, which I found complicated and hard to tackle, you might as well invest the same time and energy anyway in figuring out DBIx::Class. BTW, is there a comparison among the ORMs in Perl somewhere? It would be interesting and definitely helpful for the ORM newbies. Octavian ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/ ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Alternatives to DBIx?
On Sat, Apr 17, 2010 at 4:04 PM, John Karr brain...@brainbuz.org wrote: I think there's a very important difference of approach, much as Template Tool Kit and Template Declare, radically different approaches, that are both far superior to the classic CGI Module. Working in raw DBI is the opposite of the DRY principle which underlies having a framework in the first place, so I am seeking an alternative. Just as Catalyst uses MVC, DBIx chooses ORM, but that paradigm is not the only way to be effective PERL==SQL glue. From the Manpage Fey::SQL looks like what I want: neatly wrapped and sweetened SQL, without the repetition and overhead inherent in working from DBI. I'm going to spend some time working with it and also with SQL::DB, when I have a more educated opinion I will share it. Both Fey and SQLDB are a nativist approach to SQL (much like TT is to html), and I would argue that in keeping the PERL paradigm of many ways to accomplish a task, the choice between a SQL-native DBI wrapper and an ORM wrapper should be up to the individual, the issue seems to be finding a worthy SQL-native wrapper. In my own analysis the Time and Effort to learn DBIx is greater than the Time wasted writing repetitious DBI code, the time I've already invested on DBIx has shown that there is a better way than DBI, but for me it isn't DBIx. Please understand that DBIx means Extensions to DBI, it does not mean DBIx::Class. This is abbreviated as DBIC but not DBIx. There's a canned response to people who do this, but I'll save you that... if you look at http://search.cpan.org/search?mode=allquery=DBIx you'll see all the modules that have nothing to do with DBIx::Class that are listed there. I think Fey is a reasonable alternative if you aren't looking for the advanced features that DBIC gets you, but your general sentiment about the difference between an SQL API and an ORM is spot on. (Also, you may want to stick to writing Perl as perl is just as wrong as DBIC being called DBIx.) -J ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Alternatives to DBIx?
On Sat, Apr 17, 2010 at 4:35 PM, Octavian Rasnita orasn...@gmail.com wrote: Hi, From: John Karr brain...@brainbuz.org Working in raw DBI is the opposite of the DRY principle which underlies having a framework in the first place, so I am seeking an alternative. Just as Catalyst uses MVC, DBIx chooses ORM, but that paradigm is not the only way to be effective PERL==SQL glue. From the Manpage Fey::SQL looks like what I want: neatly wrapped and sweetened SQL, without the repetition and overhead inherent in working from DBI. I'm going to spend some time working with it and also with SQL::DB, when I have a more educated opinion I will share it. Both Fey and SQLDB are a nativist approach to SQL (much like TT is to html), and I would argue that in keeping the PERL paradigm of many ways to accomplish a task, the choice between a SQL-native DBI wrapper and an ORM wrapper should be up to the individual, the issue seems to be finding a worthy SQL-native wrapper. If the overhead/speed is the most important thing, then DBI is better than DBIC (by the way is DBIx::Class or DBIC, not just DBIx). But in that case you probably shouldn't be interested in using Template-Toolkit nor Catalyst, because they also have their overhead, and the other higher level modules used for accessing the database have their overhead also and the best solution would be DBI. On the speed note, I have a harder time getting TT optimized than anything with DBIC. TT is almost always my bottleneck, and usually harder to cache. ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Alternatives to DBIx?
Hi, From: John Karr brain...@brainbuz.org Working in raw DBI is the opposite of the DRY principle which underlies having a framework in the first place, so I am seeking an alternative. Just as Catalyst uses MVC, DBIx chooses ORM, but that paradigm is not the only way to be effective PERL==SQL glue. From the Manpage Fey::SQL looks like what I want: neatly wrapped and sweetened SQL, without the repetition and overhead inherent in working from DBI. I'm going to spend some time working with it and also with SQL::DB, when I have a more educated opinion I will share it. Both Fey and SQLDB are a nativist approach to SQL (much like TT is to html), and I would argue that in keeping the PERL paradigm of many ways to accomplish a task, the choice between a SQL-native DBI wrapper and an ORM wrapper should be up to the individual, the issue seems to be finding a worthy SQL-native wrapper. If the overhead/speed is the most important thing, then DBI is better than DBIC (by the way is DBIx::Class or DBIC, not just DBIx). But in that case you probably shouldn't be interested in using Template-Toolkit nor Catalyst, because they also have their overhead, and the other higher level modules used for accessing the database have their overhead also and the best solution would be DBI. In my own analysis the Time and Effort to learn DBIx is greater than the Time wasted writing repetitious DBI code, the time I've already invested on DBIx has shown that there is a better way than DBI, but for me it isn't DBIx. Of course that an application that uses just mod_perl handlers and not very many objects, templates, form processors, ORMs... is faster than one that use them, and for someone who doesn't know the interface of those modules is also faster to develop because no aditional learning time is required, but that application will be much much harder to maintain on the long term. If the long term development process is important, then with very few exceptions, the applications should not be optimized prematurely because there may be found other more elegant optimizations than manipulating SQL code directly. Learning the interface of DBIC takes some time, but you shouldn't learn it again and again for each new project, so on the long term the development process will be much faster. If what you don't like at all is the DBIC syntax, then yes, in that case you have a good reason for using something else, but a good idea would be to learn it a little and try to use it in order to see its benefits. Octavian ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Alternatives to DBIx?
On Sat, Apr 17, 2010 at 7:04 PM, John Karr brain...@brainbuz.org wrote: In my own analysis the Time and Effort to learn DBIx is greater than the Time wasted writing repetitious DBI code, the time I've already invested on DBIx has shown that there is a better way than DBI, but for me it isn't DBIx. I'm in no way arguing with your conclusion, such as it is; however, there's more to evaluate than just time spent learning a new library. In my experience (two or so years with DBIC/Catalyst and many, many more with sundry DBI hacks) DBIC code has proven trivial to maintain and augment. Furthermore, it's relatively easy to find programmers who are familiar with it and can be brought up to speed quickly. Your situation might be different; for me the maintenance is as important as the development. On a different note: I rarely have a need for raw SQL: what DBIC is generating is perfectly appropriate (and DBIC::Deploy does a bang-up job of creating DDL). When it is necessary, DBIC::ResultSource::View + native DB SQL code (stored procs, views, c.) does a fine job of keeping SQL out of the Perl app. (I know that opinions on this differ -- ha! -- but it's worked out well for me, particularly when I hand an SP off to a DBA for optimization; as a rule I get less grief when it's just SQL and not SQL embedded in some other language.) k. -- kevin montuori ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Alternatives to DBIx?
Octavian Rasnita wrote: But in that case you probably shouldn't be interested in using Template-Toolkit nor Catalyst, because they also have their overhead, and the other higher level modules used for accessing the database have their overhead also and the best solution would be DBI. You've literally just spelled out why my preference is CGI::Application, HTML::Template and DBI. Not knocking Catalyst, I could see it's benefits. I guess it all depends on the what kind of websites you are working on, or what your customers expect. Lyle ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Alternatives to DBIx?
On Sat, Apr 17, 2010 at 5:12 PM, Lyle webmas...@cosmicperl.com wrote: Octavian Rasnita wrote: But in that case you probably shouldn't be interested in using Template-Toolkit nor Catalyst, because they also have their overhead, and the other higher level modules used for accessing the database have their overhead also and the best solution would be DBI. You've literally just spelled out why my preference is CGI::Application, HTML::Template and DBI. Not knocking Catalyst, I could see it's benefits. I guess it all depends on the what kind of websites you are working on, or what your customers expect. Very true, which is why I use Catalyst and DBIC. I've had Catalyst+DBIC serving 10+ million hits a day. They expected fast performance, so I built and scaled accordingly. It worked beautiful. I've worked on some other high availability sites on Catalyst, with high traffic. Never had much of a problem getting good, quality results that have low deviation on performance. In addition, Catalyst being so flexible allows us to put in a great number of things with very little developer time -- hardware is much cheaper than a developer, and when you get to high end numbers that really adds up. If your developers cost less than your servers, raw DBI is probably a quite adequate solution. Glad someone is doing it, because I wouldn't touch those jobs. ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Alternatives to DBIx?
J. Shirley wrote: If your developers cost less than your servers, raw DBI is probably a quite adequate solution. Glad someone is doing it, because I wouldn't touch those jobs All depends. If you're product is to go to hundreds of customers, then the cost of them all having to buy high end servers if much more than the developer time. Plus a lot of them won't buy if it means a server upgrade. Like I said it all depends on the what kind of websites you are working on, or what your customers expect. There are lots of different angles on these things. Don't get me wrong, when I free lance I have to do Cat/DBIC/Whatever, doesn't mean I enjoy or agree with it. Lyle ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Alternatives to DBIx?
On Apr 17, 2010, at 7:31 PM, Lyle wrote: J. Shirley wrote: If your developers cost less than your servers, raw DBI is probably a quite adequate solution. Glad someone is doing it, because I wouldn't touch those jobs All depends. If you're product is to go to hundreds of customers, then the cost of them all having to buy high end servers if much more than the developer time. Plus a lot of them won't buy if it means a server upgrade. Like I said it all depends on the what kind of websites you are working on, or what your customers expect. There are lots of different angles on these things. Don't get me wrong, when I free lance I have to do Cat/DBIC/ Whatever, doesn't mean I enjoy or agree with it. I have had several Cat apps on an $8/month host for several years now. Catalyst apps don't need high end (though they do usually need a persistent execution of some kind; modperl, fastcgi, etc; RoR and some PHP stuff having the same need has helped get fastcgi on many budget hosts). Just appending that to the thread for anyone who comes in to read this and gets the impression that anything else is true. -Ashley ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Alternatives to DBIx?
On Sat, Apr 17, 2010 at 7:38 PM, Lyle webmas...@cosmicperl.com wrote: TBH if I really found the need for the DB to match up to objects, then I'd use an Object Database, not a Relational one. The only real argument for using a relational one instead, in that situation, is the performance benefits. When you want top performance from a relational database, you won't be using an ORM anyway. Actually, DBIx::Class, isn't necessarily an ORM, it's a Data Access Layer, given that inflation to objects is merely the default behaviour for it. You can very effortlessly coerce it to build an arbitrary data structure instead of objects from the data that's fetched from the database, and all the code up to the point where it inflates to objects is pretty much what you'd write if you used raw DBI anyway. Running arbitrary SQL is also very trivial to accomplish. In fact, I have a few projects where DBIx::Class is used solely as a query library and they all perform very well and were set up quite quickly, because I didn't have to spend time designing, building and testing an access layer. -- Eden Cardim Need help with your Catalyst or DBIx::Class project? Code Monkeyhttp://www.shadowcat.co.uk/catalyst/ Shadowcat Systems Ltd. Want a managed development or deployment platform? http://edenc.vox.com/http://www.shadowcat.co.uk/servers/ ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
