On Thu, Jul 16, 2009 at 01:49:02AM -0700, Darren Duncan wrote: > Tim Bunce wrote: >> On Wed, Jul 15, 2009 at 03:46:08PM +0100, Sentra Systems wrote: >>> Do you want these to be typecast to 'Any'? >> >> In the short term, yes. In the longer term we'll need to be more >> flexible. I envisage a 'type map' file that, for each Java type, >> specifies the corresponding Perl6 type (either builtin or in a module). >> Any types not in the file would generate a warning and map to Any. >> >> Feel free to add that in! I'd guess it would be straight-forward. > > On that note, I've been using what influence I have over the Perl 6 > language design in the last few years to try and improve its savvy for > relational database features and semantics. > > I currently believe, as also documented indirectly in my Muldis D language > spec, that every SQL data type of any consequence already has a direct Perl > 6 counterpart, but that in general Perl 6's version is better where different.
While that's likely to be useful in general for perl6 later, it's probably not that useful for the current goals of DBDI. We just need to be able to map the Java types used in the JDBC API to perl6 types that have sufficiently similar semantics. Remember that one of the goals of DBDI is to provide a common database API for _all_ the languages targeting Parrot. So we should avoid getting 'too clever' at this level. The Perl 6 types will be useful to whatever software is layered over the (relatively low-level) DBDI code. That's where the mythical "DBI 2" comes in. Having said all that... I expect DBDI to grow into a superset of JDBC that includes concepts and methods that enable greater performance and functionality. One significant idea here is that the higher level could should be able to supply DBDI with a row object that DBDI will just 'set' the fields of when it fetches a row. That sounds dull but it's actually significant for two reasons: a) it enables much higher performance as the same row with the same column variables (PMCs) can be reused for each row (assuming the app doesn't want to save them). That saves a huge amount of memory allocation and freeing. (That's a big part of why the DBI is so fast.) b) the field variables can be 'smart'. So, for example, the column in the row object that corresponds to an INTERVAL type could be an instance of a Perl6 Instant. Or any other object that will 'do the right thing' when the DBDI stores the value into it. Tim.
