William, To be honest, most of that framework was written to match up with some older database modules that I had inherited at my workplace. I needed something very light, and because I was already using Class::MethodMaker I went ahead and made that the basis for it. I wanted it to be light, to be able to handle lots of data, quickly. Because we use an oracle db at work, I also needed to be able to handle procedures, which Class DBI doesn't, and named sequences.
Also, I wanted the flexibility to do things a little bit more directly with the database, without it being too much of an issue. So I have the loadWithWhere methods where you can write your where clauses specifically, and loadWithParent where you don't have to, if your table subclasses are appropriately set up. My statement about mulit-keys and joins was poorly worded, really. The version of this that I have on my site right now is somewhat out of date. I decided that I wanted to make this thing available for others to use, which meant I needed to write more docs, and clean up/re factor a bunch of code. In the re factored version, joins and multi-keys work very nicely, but I am still working through that. I saw Sean's message and took it as an opportunity to let him look through another method of doing things. Probably, I should start thinking about moving over to class::dbi. I have a lot of running code that sits on top of this particular db abstraction, so I'm more than a little recalcitrant to do so. Hopefully that helps a bit. I wouldn't suggest that people avoid Class::DBI in favor of something like this, unless the implementation path I've taken here is something that appeals to them more than Class::DBI does. Thanks! caleb On Mon, 4 Oct 2004 09:53:18 -0400, William McKee <[EMAIL PROTECTED]> wrote: > > > On Sat, Oct 02, 2004 at 01:11:54AM -0400, Caleb Rutan wrote: > > That is somewhere in the neighborhood of pre-alpha. The caching stuff > > is not there, and the DB abstraction is not clean at all. It doesn't > > handle multi-column keys for tables well, nor does it do joins very > > smoothly. Those issues are almost done. > > Hi Caleb, > > Thanks for sharing your framework design. I'm curious why you don't use > Class::DBI. Is there some limitation in its design? I find that it works > just as well for external scripts accessing the database as for my > CGI::App applications. > > I had started down the road of building a custom database interface > module and am very glad to have found a community who has already made > much further progress than I had. CDBI can handle multi-column primary > keys and has some alpha support for joins. > > William > > -- > Knowmad Services Inc. > http://www.knowmad.com > > --------------------------------------------------------------------- > 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] > > -- caleb http://www.ruejulesverne.com --------------------------------------------------------------------- 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]
