Excellent framework with little better than worthless documentation. The latter often assumes a level of knowledge or expertise approaching that of the catalyst developers with the result that one can waste large amounts of time trying to solve simple coding problems.
If one make the effort to unravel how catalyst works then using it is quite easy. However, don't get me started about the DBIx::Class object-relational mapper which, after several days of trying to learn, I completely gave up on since even its useless documentation states that using raw SQL is sometimes the only means of accessing the database in the desired fashion. I use Catalyst::Model::DBI to execute canned queries and experience no problems.
Regarding object-relational mappers in general, I understand the concept of representing blocks of related data as an object, and even to some extent, abstracting the interface to the data store so the latter can be changed if necessary. I question how often a web application data store changes in its life cycle, and how a web application developer can get away with with not having a mastery of the very simple SQL language in the first place.
1 out of 3 found this review helpful. Was this review helpful to you? Yes No
Firstly, thank you to the developers involved in the Catalyst project for all their work and effort, and making it freely available for use. My comments are offered as constructive criticism.
I have spent days reading documentation, reading blogs, copying examples, etc., and have had nothing but trouble with DBIx::Class.*. I understand the bit about abstracting a data store so it can be manipulated in an object-oriented manner, but this module does not provide access to all the functionality provided by raw SQL and requires one to learn a cryptic syntax (poorly documented for real world use) that hopefully produces correct SQL. More than once the thought crossed my mind "do I have modify my database schema to cater to the limitations of DBIx::Class?". For me, this module creates cascading problems with database access, none of which I have when using raw SQL. For example, a raw SQL query that works at a database prompt when passed to DBIx::Class::ResultSource.* no longer works when it is wrapped in the default me alias. In summary, can anyone give me solid, practical reasons why I should spend a lot of time and effort trying to unravel a interface that provides less functionality and causes a multitude of problems accessing a data store than raw SQL?
I'll look at DBIx::Class again once the documentation improves and other than trivial code examples are available. Until then. I'll use Catalyst::Model::DBI and its attendant overhead, have full control of the database interaction, and waste a lot less time in getting work done.
3 out of 5 found this review helpful. Was this review helpful to you? Yes No