> Quite frankly, you already HAVE stuff to do this in CPAN. It's > practically just another Class::DBI OO->DB persistant datastore for the > most part. > > Class::DBI > SQL::Routine > Tangram > Rosetta > etc > etc > etc > > CPAN has a number of perfectly workable modules as it is.
I don't think any of them are the round peg I was looking for. C::DBI is too slow. (I had to search million++ row tables with multiple joins and return back in under 2 seconds on a low-midsize machine.) SQL::Routine / Rosetta (they're linked) are just waaaay too complicated. The learning curve is so steep that it was easier for me to roll my own than to understand their stuff. Tangram is a OO-inheritance-to-relational mapper (which is dumb to apply to the relational world, but that's another topic). I tried to get my code into C::DBI, to facilitate multi-table joins (which it doesn't do very well right now), but was put off by the complexity of C::DBI (which I've never used past sandbox). > FWIW, in my case I've tried on a number of occasions to split it out to > CPAN, about 20-30 of my CPAN modules are spin-offs from my system, but > unfortunately, the SQL generation is tied to the data type objects, > which is tied to the widget library, which is all tied to the metadata > subsystem. > > Summary, it simply can't be broken down into small enough pieces. I'm not sure that's exactly right. I know my stuff is in very small pieces. I think the problem is that there isn't very good interoperability between my pieces and your pieces. No-one decomposes the problem very well. Now, it may be a good idea to get you, me, Ovid, and whomever else involved in a solid decomposition of the problemspace and really lay out some good specs and a solid API. I'd be up for it ... Adam? Curtis? Anyone else? Rob _______________________________________________ sw-design mailing list [email protected] http://metaperl.com/cgi-bin/mailman/listinfo/sw-design
