|
pg has asked for the wisdom of the Perl Monks concerning the following question:
(The question can also be put in this way: why Perl core does not include DBI and DBD)
I always wanted to know the reason why Perl does not support database access through its core modules.
This is quite interesting (strange?), considering that:
- Database access is almost a must today
- Perl is a high level language
- We have great modules like DBI and DBD
What was the reasoning? Any story? Were they once part of the core, and then removed? (I only have a short history of using Perl.) |
Re: Why Perl does not support database access through core modules?
by rob_au (Abbot) on Jan 21, 2004 at 04:26 UTC
|
I would note that Perl does ship with support for simple hash-based databases through the DB module. The reason as to why Perl doesn't incorporate DBI and DBI-based module support within the core distribution, is most likely due to the wide variety of databases, access methods and libraries which are available for various databases - Which databases should be supported in the core? MySQL? mSQL? PostgreSQL? Oracle? SQLite? Sybase? What version of libraries for each database? Do we include pure-perl versions as well as XS versions?
There are many people who would argue that the core distribution is already bloated - The addition of support for the many databases and libraries available would only grow the distribution further.
perl -le "print unpack'N', pack'B32', '00000000000000000000001010110000'"
| [reply] |
|
|
There are many people who would argue that the core distribution is already bloated - The addition of support for the many databases and libraries available would only grow the distribution further.
I agree.
However, to me, it seems to be a better idea, to have the database access interface bundled in Perl core, but leave individual database drivers out, and have them published and maintained through CPAN or vendors.
| [reply] |
|
|
Wouldn't that kind of defeat the purpose? “This is the standard database interface for you to use, but, ehh, oh, you still have to download and install the specific driver for the database you're using.” Besides, your suggestion is already practice, you can download database drivers and the interface from CPAN, etc. and this is documented in perlfaq8.
Arjen
| [reply] |
|
|
Re: Why Perl does not support database access through core modules?
by hardburn (Abbot) on Jan 21, 2004 at 04:25 UTC
|
It does, just not databases you're probably thinking of. It has access to Berkeley DBMs by default.
As for DBI, you probably won't see it in the core. Not because it's a bad module (far from), but because there is a move twards having a much lighter core distribution. So modules are more likely to be taken out of the core than new ones put in, no matter their obvious utility.
----
I wanted to explore how Perl's closures can be manipulated, and ended up creating an object system by accident.
-- Schemer
: () { :|:& };:
Note: All code is untested, unless otherwise stated
| [reply]
[d/l] |
|
|
Yeah, but as someone who spent way too much time using SDBM and GDBM it would be nice if the Berkeley DBs were removed from the core and replaced with DBI and DBD::CSV. That way you get instant access to a lightweight database using standard DBI and SQL as well as a pre-installed hook to install whatever other DBD you need.
Of course someone probably loves the quick-and-dirty nature of the Berkeley DBM's, but I think DBI is better even for lightweight stuff. The coding/execution overhead isn't that much greater and later on it's trivial to switch out DBD::CSV with something more serious. Going from *DBM to DBI on the other hand requires a huge rewrite. Better just to encourage people to do it the DBI way to begin with, and putting those 2 modules in the core would go a long way towards doing that.
| [reply] |
|
|
Yeah, but as someone who spent way too much time using SDBM and GDBM it
would be nice if the Berkeley DBs were removed from the core
Just a note: SDBM and GDBM are *not* Berkeley DB's (DB_File is the standard
Berkeley DBM in the core). And, by the way, DB_File (and the other DBM's)
are exceedingly useful tools and should stay in the core. As for DBI/DBD,
I'm for a leaner core and one or more (semi) officially recognized SDK
packages containing database, networking, templating, et cetera.
| [reply] |
|
|
I have to agree with Trimbach, although my original post has absolutely no intention to compare Berkeley DBMs with the "database" I mentioned. (That itself could be a very interesting topic for discussion, but that is beyond what I originally asked. Personally, I don't think it should be a surprise, nowadays, to see people differentiate Berkley DBMs from conventional databases.)
It is too far from a good idea, to encourage newbies to start their database adventure with Berkeley DBMs.
When you learn, you start from the point where fits with your time in the history.
"no matter their obvious utility."
Hm...is it not true that, at least up to this day, there are more people need database access than people who need SOAP? but yet we have SOAP modules in core.
Update: See below chromatic's post for some interesting facts.
| [reply] |
|
|
but yet we have SOAP modules in core.
No, you have SOAP modules in ActiveState's distribution. That's not the core. So far, no pumpking has included an XML processing module in the core — so, no SOAP, no XML-RPC.
| [reply] |
Re: Why Perl does not support database access through core modules?
by Abigail-II (Bishop) on Jan 21, 2004 at 12:54 UTC
|
Let's address the points one-by-one.
Database access is almost a must today
Is it? I beg to differ. For many jobs, database access
is irrelevant. One of the areas Perl has been been used
a lot, even before the web was something more than a handful
of people cared about, is system administration. There, the
typical job does *not* involve access to databases that are
more sophisticated than flat ASCII files.
Besides, when the time comes that "databases access is a must", it'll be integrated in the OS. ;-).
Perl is a high level language
Not more than C, C ++, Pascal, LISP, or ALGOL. And they do
fine without database support in their "core".
We have great modules like DBI and DBD.
Yes, and? There are more great modules on CPAN. They aren't
included in the core either.
"Greatness" or "usefulness" is not a sufficient criterium for a module to be put in the core.
The more modules you put in the core, the harder it is
to maintain the core, and the slower perl development goes.
The perl core is already bloated with modules that do not
have a place in the core - and that should not be taken as
a reason to bloat it even more. IMO (and others shared that
as well), modules should only be put in the core if they
fit one or more of the following criteriums:
- They are tighted to the core, or a core feature, and
are hence often version specific (for instance B::*, pragmes, IO::*).
- They are needed to build, test or install Perl (for
instance, Test::*, ExtUtils::*).
- They are needed to fetch, build, test, or install external
modules (for instance CPAN, MakeMaker, AutoLoader, SelfLoader).
The rest of the modules does not belong in the core.
They are not needed.
Abigail | [reply] |
|
|
| [reply] |
|
|
Well, I don't support removing anything out of the core,
for reasons of backwards compatibility. But, yes, for most
of modules you list, I agree they should never have been
in the core.
As for your list, not all the modules you mention are part
of the core. LWP for instance is not part of the core - but
that's one module I think should belong in the core, if only
for the fact it's CPAN.pm's preference. For the same reason,
I don't object against the presence of Net::* (which, BTW,
is only a recent addition to the core). CGI::* and HTML::*
don't belong in the core IMO. Neither do URI::* or HTTP::*,
unless LWP would depend on them (if LWP would be in the core).
The Class::* modules shouldn't be in the core. They don't
fit any criteria I mentioned above. OTOH, modules like
File::Spec and File::Basename, and probably more of the File::* modules are used when installing perl and modules.
IPC:: can stay as well, as it's tied to core features.
I consider List::Util and Scalar::Util to be borderline cases. They are heavily tied to perl internals, and could
be quite version dependent. OTOH, the same argument could
be made for several Devel:: modules, and they live happily
on CPAN as well.
Math:: has no reason to be in the core (other than historical reasons). It lives independently on CPAN as well.
Same with Memoize.
DBMs and DB_Files have a long history. DBM support dates
from before perl5, and perl5 still supports 'dbmopen' and
friends as core features.
Search::Dict doesn't belong in the core, IMO. Text::* modules only for where they are needed to support the
POD tools.
The Win32 module isn't part of the Perl core (it says so in
the POD). I wouldn't put the POD in the Perl core either.
WWW::RobotsRules isn't in the core either.
but also what they would consider to be "core".
I think this discussion is only relevant if we consider
the "core" to be what's distributed in the perl-$VERSION.tar.gz file. That is, the file that's made
public by one of the current pumpkings.
Abigail
| [reply] |
|
|
|
|
|
|
|
|
| |
|
There are no HTML or HTTP modules in core.
| [reply] |
|
|
when the time comes that "databases access is a must", it'll be integrated in the OS
Depending on your definition of "integrated", they practically already are. ReiserFS 4 implements many features found in a DBMS (it probably has better transaction support than MySQL). I doubt we'll see a really sophisticated DBMS in any kernel, but even existing database systems work at a fairly low-level.
----
I wanted to explore how Perl's closures can be manipulated, and ended up creating an object system by accident.
-- Schemer
: () { :|:& };:
Note: All code is untested, unless otherwise stated
| [reply]
[d/l] |
Re: Why Perl does not support database access through core modules?
by greenFox (Vicar) on Jan 21, 2004 at 08:03 UTC
|
Historically Perl was a Unix language and the core modules reflect (to some extent) it's heritage. I think Berkeley DB (as mentioned by Hardburn) is supported on most (all?) Unixen whereas you would not expect other databases to be there. Most of the places where I run Perl (Unix boxes for $$$ companies and govt institutions) don't run any databases and never will. I would guess that is the normal situation rather than the exception.
Note I'm not arguing in favour of DBI/DBD not being included in the future, just speculating as to why they haven't been up to now. I will trust the Perl dev process to decide if they should be included :)
--
Do not seek to follow in the footsteps of the wise. Seek what they sought. -Basho
| [reply] |
|
|
Most of the places where I run Perl (Unix boxes for $$$ companies and govt institutions) don't run any databases and never will. I would guess that is the normal situation rather than the exception.
Really? No databases, whatsoever. Not even some xSV files?
I would hardly say that your example is a normal situation. Even if it is, I doubt it will stay that way. Certainly there is a strong move twards using RDBMS systems in web programming, where Perl has a strong following. Maybe the relational model isn't perfect for all problems, but some kind of DBMS is a strong tool to have.
----
I wanted to explore how Perl's closures can be manipulated, and ended up creating an object system by accident.
-- Schemer
: () { :|:& };:
Note: All code is untested, unless otherwise stated
| [reply]
[d/l] |
|
|
Really? No databases, whatsoever. Not even some xSV files?
In the context of the discussion I was considering DBMS and that is what people usually mean when they say database, we certainly don't have any DBA's looking after flat files :) If you want to argue that a file system or a flat file is a database then, again in the context of the discussion, Perl already has plenty of support in the core, no other modules required :) There are many types of servers which need no database for example; firewalls, mail gateways, proxy servers, web servers, applications servers... the last two may be operating as a front end to a database but run no database themselves.
--
Do not seek to follow in the footsteps of the wise. Seek what they sought. -Basho
| [reply] |
|
|
Re: Why Perl does not support database access through core modules?
by jdtoronto (Prior) on Jan 21, 2004 at 15:58 UTC
|
Well, one monks opinion!
It is interesting that database access methodologies such as you mention are not in the core, but not at all surprising. What is more surprising is what IS included in the core, and having read some of the other responses I think that in future we would be better served my a leaner, meaner core distribution. I spend most of my programming time handling databases, I love the DBI and those other things like Class::DBI that sit atop it. But what DBD would we include?
No, what we need is a better method of handling the installation of modules and distributions. What I believe we need is a system of option bundles. Let's put the CGI, HTTP, HTML, Class and whatever distributions into usable bundles which can be installed without the hassles we have now.
I am sure I will be told that installing modules is a dream. OK, in some ways it is. But as someone who is not a sysadmin let alone something resembling a sysadmin I find that working from a default install of RedHat Linux and installing Perl with all the modules I need is a huge pain in the derriere. Switching to root all the time to finish installations, especially when you are following some immense pre-requisite tree is lunacy!
Mind you, if you think Perl can be a monster, just try PHP. There is no CPAN for PHP and of all the PHP extensions I have been asked to install NOT ONE has worked, and when you ask on the various mailing lists you get told 'of course it works, you just didn't do it properly'. Thank the stars that dopesn't happen in the Perl world. For my money, leave the Perl core as it is for the sake of compatibility, but don't add any more to it and lets see if a better installation method ca be worked out for module bundles.
jdtoronto
| [reply] |
|
|
Let's put the CGI, HTTP, HTML, Class and whatever distributions into usable bundles which can be installed without the hassles we have now.
The infrastructure is there. It has been part of PAUSE/CPAN
for a long time. It's called "bundles". So, I say "put up
or shut up". Upload your bundle(s) or quit saying what "we"
should do.
Abigail
| [reply] |
|
|
| [reply] |
|
|
