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] Automated testing?
You might want to have a look at BuildBot, which is written in Python, but I've been using it for various Perl projects and find it very useful. On Sun, 2010-04-18 at 08:22 -0700, Bill Moseley wrote: I have a cron job that watches for changes to SVN, and when found the cron script exports the code and runs the tests. The idea is to notify developers if they check in code that causes testing to fail. I'd like to move away from using my custom scripts to a more generic tool that will do automated testing for all our packaged Perl code, not just the Catalyst apps. (Since the Catalyst app is just another Perl distribution). Perhaps something similar to what cpan testers use where email notifications are sent but also provide a web-based history of testing. Do you do anything similar? Anyone using Smolder and/or SmokeRunner::Multi or other standard tools for their in-house code? Thanks, -- Bill Moseley mose...@hank.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] [Beginner] How to get 'Chained' to work`?
Am 15.04.2010 14:56, schrieb Steve: Actually, I found the documentation in Catalyst::DispatchType::Chained to be fairly comprehensive. You might want to give it a once-over. You're right: reading the mentionend documentation is indeed fairly comprehensive. Am 15.04.2010 16:04, schrieb Tomas Doran: Johannes Kilian wrote: Thank you - that was the problem ... It's difficult to find a documented entry to this (Chained/Args/CaptureArgs ...) with (nearly) zero knowledge. Can you tell us where you tried to look for the info, and I'll make sure some helpful hints get added too the documentation? Cheers t0m My main error was (as a catalyst beginner): having an isolated view on the chained argument not recognizing that chained - args - PathPart - CaptureArgs are related so closely. Having understood the Chained-mechanism, it's clear that it has to be so - but the first barrier to get this understanding was too high. Mainly I used The definitive Guide to Catalyst-book as first approach - from which I assumed to be a step by step tutorial (which it is - but the steps are bigger than I realized in this case). I started the tutorial just in the middle (not having all prerequisites) and started testing it, without having all the comprehensive information - and run into the discussed questions ... (And most badly: I used a helpfile which don't have Args und CaptureArgs in the search index - but Chained was available, so I thought, there's no docu on those Arguments ...) After rereading everything - there's all information available. I just followed the old principle Engineers don't read manuals (or if they do, they only read small parts - which I did ... ;-) Cheers Jo ___ 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/
Follow Up: [Catalyst] Alternatives to DBIx:Class?
Most of the responses to this thread seem to say that DBIC is worth the effort. I looked at Fey:SQL and SQL::DB and concluded that they also require some effort, and suffer (along with DBIC) from what is for me a huge issue -- the documentation focuses on telling you how each piece works rather than on how to drive the darn thing. At this point for everything I'm working on, I have the luxury that I can write all of my joins and complex statements into a view or stored_procedure, but in the real world programmers are too frequently denied this, so even though right now I would like something that just wrapped the DBI up in a manner that made it easy to write and keep the DRY principle, it would be potentially more valuable to learn DBIC or Fey. DBIC is the more widely adapted solution, while Fey seems to offer most of the same capability with a syntax that draws on SQL (which is a lot of points in its' favor), but has less momentum and lacks equivalents of some of the helper scripts that are available for DBIC. So let me ask a follow up: What materials would you provide to an Intermediate Level Programmer to help them learn either Fey or DBIC? Materials could be working code, articles, things in documentation, documentation for other things that happens to explain it well, chapters in books, etc. Afternote. There is a tutorial in Fey::ORM's documentation, but it is more of a quick run-through. DBIx::Class has a better introduction in its' documentation, but that hasn't helped me much. The tutorial Kennedy Clark wrote for the Catalyst Manual was how I figured out Catalyst. Again developer isn't my normal job title, I will probably never get paid for knowing anything about ORM, time I spend learning it is only a benefit if it gives me pleasure (not so far) or saves me time in the long run (the clock is running the other way). -Original Message- From: Hakim Cassimally [mailto:hakim.cassima...@gmail.com] Sent: Monday, April 19, 2010 7:59 AM To: The elegant MVC web framework Subject: 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/ ___ 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: Follow Up: [Catalyst] Alternatives to DBIx:Class?
Hi, On 2010-04-19 22:37, John Karr wrote: Most of the responses to this thread seem to say that DBIC is worth the effort. I looked at Fey:SQL and SQL::DB and concluded that they also require some effort, and suffer (along with DBIC) from what is for me a huge issue -- the documentation focuses on telling you how each piece works rather than on how to drive the darn thing. At this point for everything I'm working on, I have the luxury that I can write all of my joins and complex statements into a view or stored_procedure, but in the real world programmers are too frequently denied this, so even though right now I would like something that just wrapped the DBI up in a manner that made it easy to write and keep the DRY principle, it would be potentially more valuable to learn DBIC or Fey. DBIC is the more widely adapted solution, while Fey seems to offer most of the same capability with a syntax that draws on SQL (which is a lot of points in its' favor), but has less momentum and lacks equivalents of some of the helper scripts that are available for DBIC. So let me ask a follow up: What materials would you provide to an Intermediate Level Programmer to help them learn either Fey or DBIC? Materials could be working code, articles, things in documentation, documentation for other things that happens to explain it well, chapters in books, etc. Afternote. There is a tutorial in Fey::ORM's documentation, but it is more of a quick run-through. DBIx::Class has a better introduction in its' documentation, but that hasn't helped me much. The tutorial Kennedy Clark wrote for the Catalyst Manual was how I figured out Catalyst. Again developer isn't my normal job title, I will probably never get paid for knowing anything about ORM, time I spend learning it is only a benefit if it gives me pleasure (not so far) or saves me time in the long run (the clock is running the other way). Since you've mentioned stored procedures I'm letting myself to mention DBIx::BlackBox. I've created it at $work to ease the integration of my Catalyst app with existing MS SQL database with hundreds of tables, views and stored procedures. The main driver was that I don't really want to learn all relationships between those tables + I've got very skilled DBA in my team who already knows this database :) So all those complex queries can happily live and be optimized at database level, while I can deal with data returned by those stored procedures. But I'm a huge fan of DBIx::Class and I can assure you that time spent on learning it won't be wasted, because maybe with your next job there won't be so complex queries and typing SELECT t1.col1, t2.col2 FROM tab1 JOIN tab2 all over the place is just a waste of time if you can simply write $tab1-col1, $tab1-tab2-col2. Regarding documentation I've found DBIx::Class man pages good enough + most of the Catalyst examples/blogs are bundled with DBIC ones. Cheers, Alex ___ 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] Automated testing?
On Sun, Apr 18, 2010 at 08:22:56AM -0700, Bill Moseley wrote: | I have a cron job that watches for changes to SVN, and when found the cron | script exports the code and runs the tests. The idea is to notify | developers if they check in code that causes testing to fail. | | I'd like to move away from using my custom scripts to a more generic tool | that will do automated testing for all our packaged Perl code, not just the | Catalyst apps. (Since the Catalyst app is just another Perl distribution). | Perhaps something similar to what cpan testers use where email | notifications are sent but also provide a web-based history of testing. | | Do you do anything similar? Anyone using Smolder and/or SmokeRunner::Multi | or other standard tools for their in-house code? I can recommend Smolder--it's pretty nice. I have it hooked up to an svn commit hook so when people commit it uploads using smolder_smoke_signal. Amiri ___ 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: Follow Up: [Catalyst] Alternatives to DBIx:Class?
John Karr wrote on 4/19/10 4:37 PM: So let me ask a follow up: What materials would you provide to an Intermediate Level Programmer to help them learn either Fey or DBIC? Materials could be working code, articles, things in documentation, documentation for other things that happens to explain it well, chapters in books, etc. Rose::DB::Object (RDBO) hasn't been mentioned much in this thread. It has good manpage-type docs, and a decent intro tutorial: http://search.cpan.org/dist/Rose-DB-Object/lib/Rose/DB/Object/Tutorial.pod There is also Rose::DBx::Garden::Catalyst for bootstrapping an entire Cat app using RDBO: http://www.catalystframework.org/calendar/2007/7 -- Peter Karman . http://peknet.com/ . pe...@peknet.com ___ 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/
