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/
[Catalyst] Re: Alternatives to DBIx?
On Sat, 17 Apr 2010 14:35:51 +0100, Lyle wrote: 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. Ok, I'll bite: What system do you use instead of an object-relational mapper? Best regards, Adam, who, while curious, quite likes DBIx::Class; especially compared to other solutions I've tried. -- It's my chainsawAdam Sjøgren Come see how it shines a...@koldfront.dk I'm gonna cut out a living I'm gonna cut out your kind ___ 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] Re: Alternatives to DBIx?
Adam Sjøgren wrote: On Sat, 17 Apr 2010 14:35:51 +0100, Lyle wrote: 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. Ok, I'll bite: What system do you use instead of an object-relational mapper? At the moment I just use DBI directly. Probably try DB::SQL next Everyone is entitled to their own opinion. 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/
[Catalyst] Re: Alternatives to DBIx?
On Sat, 17 Apr 2010 19:15:14 +0100, Lyle wrote: Adam Sjøgren wrote: Ok, I'll bite: What system do you use instead of an object-relational mapper? At the moment I just use DBI directly. [...] Thanks for the answer. It is always nice to know what people like when they express contempt for other things. It gives you a chance to understand where they are coming from better. Everyone is entitled to their own opinion. Sure, but you can state your opinion in many ways. Some more conductive of a good, nuanced discussion, than others. Best regards, Adam -- I always liked songs with parentheses in the title.Adam Sjøgren a...@koldfront.dk ___ 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] Re: Alternatives to DBIx?
Adam Sjøgren wrote: On Sat, 17 Apr 2010 19:15:14 +0100, Lyle wrote: Adam Sjøgren wrote: Ok, I'll bite: What system do you use instead of an object-relational mapper? At the moment I just use DBI directly. [...] Thanks for the answer. It is always nice to know what people like when they express contempt for other things. It gives you a chance to understand where they are coming from better. Personally, I prefer a middle-ground between raw DBI+SQL and ORMs as they are currently known, and that's what my Muldis D language and database toolkit is meant to deliver. People could treat it like a SQL templating system in the way that things like SQL::Abstract are treated, but that it is a lot more thorough in features and makes the SQL look more like Perl; your database tables are expressed as data type definitions plus declared variables of those types; your queries are expressed as mostly-declarational functions and procedures. You can write Muldis D either in string form like with SQL or Perl, which is better when you're writing code entirely manually, and you can write it as Perl data structures, which is better if you are generating code using Perl, both forms equally expressive; the latter is the closest analogy to traditional SQL generators. Muldis D is like a traditional ORM in that it has a variety of built-in features that SQL DBMSs in general lack, such as updateable views or collection-valued attributes, say to nest child records under parents. But unlike typical ORMs, it unifies objects and the relational model, and so considers that there is no impedence mismatch, while ORMs say there is a mismatch and tries to treat the two things as separate. In other words, Muldis D makes the database itself look more powerful or Perlish than it otherwise is, and so Perl programs can then use it as if it were just an ordinary programming language VM, based on types and routines like regular languages. I am perhaps a few days away from a milestone in this project and I wasn't going to talk about it here before that; but this thread sort of forced my hand as I didn't want the option to go unmentioned in it. -- Darren Duncan ___ 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/
