I have looked into CDBI a bit more (it was I that started all of this several days ago). I am still concerned about handling joins. I agree that it (CDBI) looks fantastic for getting information from a single table at a time, but I often need to pull data from different columns in several tables at a time or perform a join (or multiple) to get the information that I want.
CDBI objects map single rows from single tables. If you're pulling data from several tables at once, then that doesn't map nicely to objects. You could take a look at Class::DBI::View, which implements - surprise - views. I think that comes closest to what you're looking for.
For some join related hints, see the stuff we wrote on the cdbi wiki: http://www.class-dbi.com/cgi-bin/wiki/index.cgi?UsingJoins and other pages.
In my particular case, I have some 50 tables, many with only 2-3 columns because of the relationality of the data, so performing multiple selects to "drill down" to data from a fourth or fifth join using the CDBI framework seems quite tedious and successfully defeats the power of modern SQL engines for performing these joins in a very systematic fashion, using more than just a primary key if possible. I recognize that CDBI still allows the flexibility of straight-up SQL, which is why I may ultimately use it, but I am curious if there is more coming along in joins than has been discussed. This is certainly getting outside the realm of CGI::App list, but I have had so many recommendations from users here that I thought I might benefit from a tad bit more insight.
We're currently building a large set of apps for Spirit of America, a non-profit organization aiming to help Americans serving in Iraq & Afghanistan to assist the people in need. (www.spiritofamerica.net, but it's not live yet). It's based on CGI::Application and Class::DBI, running under mod_perl. We're at around 60 tables right now, and developing it is a pleasure. One nice thing I managed to do is add a member search, using a join in the Member class on all related tables (addresses, skills, etc.). That way you can query it on every possible combination of features, with the help of SQL::Abstract, and still benefit from the SQL engine to do the joins.
I am constantly amazed by the speed with which we manage to add new features, and by how well it works: the separation makes it very stable, and easy to debug.
Rhesa
--------------------------------------------------------------------- Web Archive: http://www.mail-archive.com/[EMAIL PROTECTED]/ http://marc.theaimsgroup.com/?l=cgiapp&r=1&w=2 To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
