Front page | perl.dbi.dev |
Postings from November 2016
RFC: Official DBI for Perl 6
Thread Next
From:
Darren Duncan
Date:
November 24, 2016 01:06
Subject:
RFC: Official DBI for Perl 6
Message ID:
f77733f3-999f-a5e4-8d06-01179e53833a@darrenduncan.net
This message is an RFC regarding Perl 6 and my proposed official successor there
for the current Perl 5 "DBI" module, and in particular for usage of the "DBI"
namespace.
For context, Perl 6 only now is starting to be treated by the community as an
actual usable-in-production language similar to lots of other languages like
Perl 5 or Ruby or Python or the hundreds of others. Rakudo is reasonably stable
and complete, but with lots of work continuing on it. Multiple books are being
written on Perl 6. A collection of modules exists. And so on.
I believe that now is the time for a serious look at having an official "DBI"
for Perl 6. As Perl 6 has become more stable and is starting to have actual
users and books etc, what database-access solutions exist now or in the near
future are likely to set the trend for the next while, and its important to have
something good very soon so the trend is something easier to maintain and
something we would be proud of. While DBIish exists now, I see that as an
intermediate placeholder, so self-proclaimed I think, and its time for a real
thing of sorts to come forth.
I have already been working on a "Perl 6 DBI" or "Plack for databases" for
awhile now, and in a few weeks I should be ready to show it off for evaluation.
But in the meantime, I was hoping to get Tim Bunce and other community
stakeholders on board with its philosophy and get a blessing to use the name
"DBI" for it.
In this message I will outline a few main points to start off the discussion,
and other details can follow in the near future.
1. This "DBI" design is actually meant to be language-agnostic in several
senses. This particular thread would focus on Perl 6, but the intent is that
the designs in question would also have corresponding versions for Perl 5 (name
yet to be determined) and other languages. I intend for a family of related
projects, but the one for each language would be independently managed in a
formal sense, even if informally the same people work on several of them.
2. The single most important design is that the new "DBI" ecosystem is
"shared-nothing". That is, the new "DBI" would actually just be an API
specification document for a duck-typing/etc API that conforming libraries and
applications would implement for themselves. A conforming library would either
provide the API or consume the API. Example providers are direct analogies to
eg DBD::SQLite, DBD::Pg, and so on. Example consumers are either end-user
applications or some kinds of middleware such as analogies to DBIx::Class,
Rose::DB, and so on. Sometimes you can have libraries that are both providers
and consumers, such as a proxy layer or an emulation layer. There would
absolutely NOT be any code/module/class/role/etc named "DBI" which consumers
would need to "use" to mediate access to providers. There would absolutely not
be any mandatory shared dependency such as "DBI" to use the shared API. This
doesn't rule out the existence of libraries that provide implementation code
which API providers can choose to depend on in common, such as DBI is often used
for today, but this would strictly be an implementation detail of the providers,
and not mandatory for using "DBI".
3. When a consumer wants to use a DBMS, they would for example "use DBD::Pg"
directly. Or in the common case where one wants to have a consumer that is
agnostic to provider (for some meaning of agnostic) and the provider is
indicated in a user-written config file, we use duck-typing/etc to do this
cleanly. Assuming each provider would use multiple classes/etc to implement the
API, but that there is a root class or module that they use first such as what
they invoke to say "give me a database connection" or such, that root class
would work like this: The root class/module would provide a stateless routine
that acts as a magic cookie; the consumer would use Perl's basic introspection
abilities to query if the package name given from the config file declares a
routine with that name, and if it does, assume that the package has formally
declared it provides the "DBI" API. Maybe the routine could be called
provides_DBI_for_Perl_6() or some such. And then there would be a routine to
call on the same root package where the consumer can ask what versions of the
DBI API are supported and/or ask if a particular version of the API is
supported. Versioning would have at least the triplicate
base-name/authority/version-number analagous to Perl 6 package versions. And
then the consumer can then go from there to introspect details of the provider's
capabilities and actually use it.
4. All introspection or generally all use of the API involves invoking expected
routines/methods/etc, and there are NO checks for whether packages or objects
compose particular roles or have particular names or even assume particular
hierarchies for implementing classes etc.
5. This new DBI would make no core assumptions on what query/instruction/etc
languages each provider understands or uses natively or how data is represented
or what data types are supported. It treats on equal terms whether we have
relational or nonrelational, SQL or non-SQL, and so on. But it would still
remain savvy to relational in particular. A consumer would be able to
introspect the language capabilities using the API, including in the case of SQL
what versions of SQL are supported, so that the consumer can programmatically
know what options it has for providing queries. For example, the Enterprise DB
version of Postgres may accept both Postgres and Oracle versions of SQL for
querying. While the Perl 5 DBI gives lip-service to being agnostic to query
language or paradigm, a lot of its hard-coded API is still specific to details
of SQL or ODBC etc.
6. All query/instruction etc is treated as just data to the main API itself,
same as any result or regular input data is, and executing instructions is a
separate step from feeding them in the form of data into the provider.
7. The main API has generic Value objects representing data of any type,
whether scalar or collection or code etc, and the API details for executing
queries are arms length from the API details for marshalling data between
regular Perl data types / data representations and these Value objects.
So that's what I have to say in my first message, and other details are pending.
Does this sound like a proposal you can get behind, is it okay to use "DBI" for
the name reserved for the specification (occupied by POD files say but no code),
do you have any questions or counter-proposals, and so on? Also, when this
proposal is adopted in Perl 5, what namespace should it have?
Thank you in advance.
-- Darren Duncan
Thread Next
-
RFC: Official DBI for Perl 6
by Darren Duncan