Sam Tregar wrote: > >>I've not drawn any money from it yet and doubt that I will myself. >>(I'm considering suggesting that the Perl Foundation make payments >>from the fund to people making specific contributions to the DBI. >>I'm thinking especially of work on a comprehensive test harness. >>But I'll see how the developments below pan out before making >>specific arrangements.) > > > How much development will $500 buy? It seems like the funding drive > was a failure. Maybe skip talking about it or move it to a separate > email? (Yes, I'm treating this like marketting.)
Er, marketting in what way ? Developing DBI/DBDs costs time & resources. Many major for-profit orgs are leveraging DBI (and Perl in general) to make lots (and I again mean *lots*) of money. Asking them to pony up some modest contributions (or at least staff time) *for their own benefit and security* doesn't seem like "marketting" any more than this weekend's Live 8 concert is "marketting" for starving children in Africa (ok, maybe thats not a PC metaphor, but hopefully it gets the point across). The fact they choose to "live off the fat of the land" is more than a bit frustrating. If anything, perhaps DBI and DBD authors should use a MySQL type dual license to cover the development/support costs. > > >>Which sums up fairly well where I'm at: DBI v1 will rumble on for Perl 5 >>and DBI v2 will be implemented for Perl 6. > > > My first reaction to this was not good, mostly because I expect Perl 6 > to take a long time to reach a state when I can use it for real work. > However, on further consideration I think this is a reasonable > approach. Perl 5 doesn't need a DBI 2 - DBI 1 is working great! Well, maybe. While Perl5, DBI, and threading may never be able to mix properly, it would be nice to be able to exploit them in large scale/complex apps, which I fear Perl6 may not be capable of for 2+ years. And Perl5 will live on long after Perl6 has fully ripened. > > Well, since you asked, my list: > > - Asynchronous queries (coroutines? threads?) Threads. If you've ever done much Java/JDBC work, you'll realize how much simpler a solution to async it is. (Ignoring the rest of Java/JDBC's undesirable traits) > > - High-level support for cursors Seconded. > > - Ditch magic tied attributes and route all access through method > calls. This would make sub-classing (and programming) DBI easier, > in my opinion. I'd vote against "ditch", maybe provide accessor/mutator i/fs for those that desire them. Some of us still prefer a declarative approach. (In fact, I'd vote for a fully declarative i/f to *everything*, but that would likely scare the OO crowd away, it certainly keeps them away from SQL::Preproc !^) > > - Default RaiseError to 1 (pretty minor but I see a lot of pain > related to missed errors) I'd think the native exception handling would be the proper paradigm. At which point things like RaiseError, PrintError, HandleError, etc aren't really needed. > > - Integrated transactions and Perl 6 try/catch semantics? It seems > like they're often used to address the same problem but I'm not > sure what the right integration is. Not certain what you mean by "integrated transactions" ? I'd suggest a peek at JDBC. An explicit indication of "inside transaction" or "outside transaction" would be nice. > > -sam > I think some of the following have been raised before, but to reiterate: 1. A standard conformance test suite for DBDs: a very big (and likely mundane) chore, but really needed/valuable. 2. Full thread safe support. 3. A std. i/f for multistatement result sets. 4. Std. 2PC i/f (XA) ? 5. A better set of metadata for DBDs to report the functionality they support. E.g., today, the only way to find out if a DBD is threadsafe (at runtime) seems to be try it and hope for the best. 6. Std. i/f support for exotic datatypes (intervals, UDTs, ARRAY, etc.) 7. Better docs for DBD developers (hopefully PDBI2E will address this ?) 8. (I know I've argued against this in the past, but I've had a change of heart) DBI inclusion as a Perl CORE module. Database access is too prevalent these days for it to continue as an afterthought, and it would likely increase test coverage/exposure. Now, if only I had time to pitch and resolve some of these (tho I may, of neccesity, help solve Perl5 thread issues in the near future). My 0.02, Dean Arnold Presicient Corp.
