Beefy Boxes and Bandwidth Generously Provided by pair Networks
Perl: the Markov chain saw
 
PerlMonks  

Why Perl does not support database access through core modules?

by pg (Canon)
on Jan 21, 2004 at 04:20 UTC ( #322779=perlquestion: print w/ replies, xml ) Need Help??
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.)

Comment on Why Perl does not support database access through core modules?
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

      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.

      Gary Blackburn
      Trained Killer

        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.

      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.

        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.

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'"

      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.

        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

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

      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

        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

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:

    1. They are tighted to the core, or a core feature, and are hence often version specific (for instance B::*, pragmes, IO::*).
    2. They are needed to build, test or install Perl (for instance, Test::*, ExtUtils::*).
    3. 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

      To paraphrase, you would support dropping about half the modules in the core in 5.10 (or .12 or whatever). That list of modules would probably include (if I'm reading you right):
      • The CGI::, HTML::, LWP::, Net::, URI::, and HTTP:: namespaces
      • The Class:: namespace
      • The File:: and IPC:: namespaces (including File::Spec and File::Basename)
      • List::Util and Scalar::Util
      • The Math:: namespace
      • The Memoize:: namespace
      • All the DBMs and DB_File
      • Search::Dict
      • The Text:: namespace
      • The Win32 module
      • WWW::RobotsRules (and friends)

      I'm in complete agreement with your three criteria, but I don't think most people involved in this debate realize not only what's in the core, but also what they would consider to be "core".

      ------
      We are the carpenters and bricklayers of the Information Age.

      Please remember that I'm crufty and crochety. All opinions are purely mine and all code is untested, unless otherwise specified.

        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

        There are no HTML or HTTP modules in core.

      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

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

      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

        Touche!

        I feel an accelerated learning curve coming on.

        jdtoronto

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: perlquestion [id://322779]
Approved by xenchu
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others lurking in the Monastery: (5)
As of 2014-12-28 10:29 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    Is guessing a good strategy for surviving in the IT business?





    Results (180 votes), past polls