Darren Duncan skrev:
> Hello again, and thanks for the replies. And now we have 6
> posters to the list.
Another lurker unlurks (briefly).
>
> My current understanding is that we want the entire PDBI core
> to be written in PASM/IMCC. Likewise, we want all of the PDBI
> drivers to be written entirely in PASM/IMCC, assuming that
> Parrot's NCI can understand by itself how to talk to each
> database product's native C driver. And so the *only* time we
> drop down to writing actual C code is if a native database
> driver does something funky with its interface that NCI doesn't
> understand; and even then, our C code would be minimalist and
> do just enough to wrap the native driver so that NCI does
> understand it; and even then, the C stuff will always be part
> of a driver and not part of the core. (This is unlike DBI
> where the framework is mostly C/XS.)
That seems sensible, but does need some carefull thought about
the interface between the DBDI and the drivers. Several driver
authors have expressed wishes for (minor) changes during the
discussion on dbi-dev just before the announcement of this
project.
I am certain that when I begin to implement my driver on DBDI
taht I will have a number of wishes for utility function that
the DBI layer should provide. Eg. most if not all drivers have
implemented their own preparsing of the SQL to handle placeholders
and all drivers store the SQL-statement in $sth->{Statement}.
There is probably a number of similar functions needed in the new
framework.
>
> I also see a big advantage here where the dichotomy of the
> current DBI core, one in XS and one in pure Perl 5, will go
> away. There would be a single core instead.
>
> So, some more questions:
>
> 1. Is my above understanding correct?
>
> 2. One of DBI's touted strengths is its speed. So while Parrot
> itself is being designed and worked over to deliver maximum
> performance of all PASM/IMCC code, is it going to be enough
> such that a completely interpreted PDBI framework will have
> comparable performance to the old DBI? Or do you see the
> project sacrificing a fair amount of speed (at least in the
> short term) by not being written mainly in C?
My belief is that in database processing you can "waste" quite
a lot of time processing the queries without it being significant.
The one place where everything has to be fast is during the fetch
phase - avoiding too much copying of data back and forth is the
(or rather one of the) main reasons for DBI's speed in this area.
It doesn't matter if you shave of a few microseconds on an execute,
that is going to disk on another node in the network - cause that
will be dwarfed by the latency in the other parts of the processing.
>
> I mean, in my mind all the gains we would have from going all
> Parrot native far outweighs any down sides. But my point in
> asking is whether anyone sees this as a concern such that they
> may decide to move parts of PDBI (core particularly) to C later
> on. Or is such a move going to be expressly avoided in principle?
My understading is that we would stand to gain very little (probably
nothing) by going to C instead of IMCC. We would lose all the
benefits of garbage collection (oh the number of hours I have spent
trying to track down memory leaks), PMCs and their interface to
"host"-language datatypes, and so on and on.
>
> 3. Would you say that PDBI would be best off, from an API /
> features point of view, to basically port DBI to Parrot and
> have people keep using it as they always have, such as what
> Ponie does for Perl 5? In fewer words, is PDBI supposed to be
> a Ponie rather than a Perl 6?
I would prefer it to be a DBI v2 - like Perl5 to Perl4, ie. a minor
upgrade keeping (nearly) all the backward compatibility (we know
that the DBI is good) but adding a hooks for new and improved
functionality (but it can be better :).
>
> 4. As once-core features of Perl 5 have been ejected from the
> core for Perl 6, such as networking or 'format', is it
> reasonable for us to actually make PDBI *thinner* than DBI,
> taking old core features and requiring them to be plugins?
No, not the DBI itself. There is some added value in the DBI
distribution, that may be taken into a separate module,
eg DBI::Shell and DBD::Proxy (but they are already there..).
> I ask this partly because, while people say that the DBI or
> PDBI core shouldn't be doing any query generation, I see that
> it is in fact doing some of this already. One example concerns
> 'bind variables'. While some databases natively understand
> bind variables, I am seeing some DBD modules not using such a
> facility but rather are doing their own string search and
> replace to interpolate such values into the SQL string, and
> then sending said string sans any remaining variables to the database.
Yes correct, but that is not the DBI, that is the DBD implementing
the DBI specs - a wholly other kettle of fish.
In my view the DBI is:
a) a spec defining the API of the user-perl-code - DBI interface
b) a spec defining (not so well, but "read the code Luke" defining it)
the interface between the DBI and the different DBDs.
c) a number of utility functions that aid the drivers in doing
their stuff
The DBDs implement, in a multitude of different ways, the DBI<->DBD
spec hiding as much of the peculiarities of the underlying DBMS as
needed/possible/whatever.
The DBIx modules add value to this in their mysterious ways...
And I envision your Rosetta project as one of those.
--
Henrik Tougaard, [EMAIL PROTECTED]
DBD::Ingres maintainer
