Re: Database for gnome
- From: Peter Norton <spacey inch com>
- To: shendrix escape widomaker com
- Cc: gnome-list gnome org
- Subject: Re: Database for gnome
- Date: Sat, 7 Feb 1998 15:31:07 -0500
On Sat, Feb 07, 1998 at 02:03:46PM -0500, Charles Shannon Hendrix wrote:
> In message <19980206144506.62792@inch.com>, Peter Norton writes:
> > Using DBI is absolutely the wrong approach for gnome. The reason I say
> > this is that DBI is currently only a layer on top of a particular vendor's
> > CLI.
>
> Um... I don't think so. I just built the Oracle DBD yesterday and it
> seems to me it uses SQLnet. I know that the C code needs to see the
> Oracle client libraries on my development machine.
[Note, I've added all of oracle's "*"'s to their product names because
they make the names look silly]
SQL*Net is a protocol that oracle defines which is essentially layered on
top of Oracle's CLI (or as they call it OCI, Oracle Call-level Interface),
which can only be acessed by linking to an oracle library. This is
essentially the same thing, because SQL*Net is the protocol that make
Oracle network accessable. Try putting together DBD::Oracle on Linux -
just the client side, to get data off of your nearest server. In this
case, DBI/DBD hassn't yet liberate you from the vendor's restrictions.
> I'm curious enough to check in detail (I've used Perl DBI for a couple
> of years now) but I know that quite a few of the sqlplus commands will
> not work in Perl DBI with the DBD for Oracle.
SQL*Plus defines it's own primitives that don't conform to SQL for the
sake of making the use of the database easier. I.e. "desc tablename" -
obviously not a sql statment (no termination semicolon) will return a
rough approximation of the layout of your table "tablename". This sure
isn't defined anywhere in SQL - it's something oracle does to make their
product more useable.
> > The second part of my reasoning is that if we support ODBC as the
> > underlying mechanism, then perl's DBD::ODBC will be able to use these
> > services, python's ODBC bindings will, as will any already written ODBC
> > applications. That's a mcuch bigger win, because it supports more choices
> > and more easily.
>
> This is true.
>
> > If we use DBI, then we'll have to write an entire ODBC interface for it
> > anyway, and we'll be relying on the still un-finalized DBI/DBD interface.
>
> Why? Doesn't it already have one?
It seems like the DBD::Oracle distribution goes out of it's way to point
out that the only currently stable interface is Oraperl, and that the DBI
interface is far from final. It's been that way for the last year, so I
presume that there are still issues to be worked out.
> My biggest problem with this is the overhead of Perl in the mix.
> You would have to create a long-running server daemon for it to really
> work well and that will eat lots of RAM and CPU.
Perl is far too much overhead to incurr to make a job like this possible.
-Peter
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]