Hello again, and thanks for the replies. And now we have 6 posters to the list.
At 10:01 AM -0800 2/7/04, Jeremy Brinkley wrote:
>The NCI should allow most libraries to be loaded and called into without
>wrapping with C glue; but some, depending on their quirkiness, may require
>a wrapper in C. ... The underlying platform's dynamic loading mechanism. Check out
>docs/pdds/pdd16_native_call.pod.
Well, that clears things up for me immensely. Following that ...
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.)
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?
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?
At 10:29 AM -0800 2/7/04, Jeff Zucker wrote:
>Hi from one of the whoevers. It seems to me that recreating the functionality of the
>current DBI is goal #1, no matter what other goals might be in mind. It also seems
>to me that an attempt to create an Ur-SQL, while noble and worthwhile, is a separate
>enterprise that should be accomplished with extensions to the core, but that's just
>my uneducated $0.02 as I haven't yet had time to investigate your Rosetta project.
At 10:01 AM -0800 2/7/04, Jeremy Brinkley wrote:
>I'll comment that for my money merely having DBI-style functionality
>available for other languages is enormously worth it, I'd argue the
>successful design of the DBI argues against changing its core features.
>OTOH extensibility is a good thing, so perhaps providing easy ways to
>extend the DBI is the way to go.
>
>It would seem to me that query generation is naturally a separate thing
>from communication. On the other hand, I think it would be a useful feature
>for the DBDI to provide hooks at various stages of statement handling,
>allowing separate small modules to provide things like query rewriting or
>data-dependent connection dispatch. This might very well be a current
>feature of the DBI; I haven't checked in in a while.
I agree that communication and query generation are naturally separate in principle.
Likewise, for the most commonly used database products that understand a rich SQL
dialect natively, the PDBI core and its drivers should focus on just the relatively
simple issues of communication. This means that they do nothing except take SQL
queries as input, forward them to the database, and return the results. Much as DBI
does now. That keeps the core simple, and facilitates the maximum possible access to
the unique features of each database. This sort of thin PDBI can be wrapped
effectively to do the added functionality that I want.
However, one place I see this breaking down is in situations where the database or
other service we are talking to doesn't natively take SQL as input, but something else
instead. In these situations, the current DBI continues to take SQL strings as input,
while the "driver" then goes to the trouble to parse those and render commands in the
native fashion. Part of what my Rosetta project was meant to save people from was
having to generate SQL statements and then go to the trouble to parse them again.
I definately agree that the PDBI architecture should be designed with hooks so that it
could be extended internally, perhaps using Apache 2 as a model. This way, some
drivers could allow you to send them query objects rather than query strings; the
drivers would then have a lot less work to do in figuring out what the application
wants it to do.
... I forget what else I was going to say ...
Essentially, I hope that this process in developing PDBI may allow us to not hold
anything sacred, and be open to doing to DBI what Perl 6 does to Perl 5.
On the other hand, Tim was quite up front in saying that he wanted PDBI to be *a*
database interface for Parrot, rather than *the* interface.
So here's another question:
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?
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?
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.
Another example which particularly concerns me is things like the "{fn ...}" and the
"{ts ...}" stuff you plan to add to prepare(), so says your Advanced Talk. This in
particular looks quite hackish. Generally speaking, I believe that if DBI / PDBI
isn't going to endorse elegant full scale query generation in the core, then it should
avoid such half-baked attempts at integrating SQL portability like I saw in the
Advanced Talk.
Generally speaking, because query generation is potentially a very complicated task, I
believe that it should be kept soley in the domains of plugins, such as what my
Rosetta project would likely become. As the Unix philosophy goes, have several
components that each do one thing well rather than one that tries to do several.
Anyway, there's my next 3 cents.
Have a good day. -- Darren Duncan
