Why Python has no equivalent of JDBC of Java?

[Peter J. Holzer]

On 2019-06-16 15:45:42 +0200, Marco Sulla via Python-list wrote:
> On Tue, 21 May 2019 at 01:20, Michael Torrie <torriem at gmail.com> wrote:
> > On 05/20/2019 04:23 PM, Andrew Z wrote:
> > I assume
> >
It would have helped if you also quoted what Andrew assumed, not just
that he assumed something.

For the record, he assumed that JDBC also needs a native driver but that
this is automatically installed. (the assumption was wrong)

> Nope, it requires the instantclient and, on Linux only, also the
> installclient-devel package. And a bunch of obscure and terrible settings,
> like LD_LIBRARY_PATH...

If "it" means the Oracle JDBC driver, then it doesn't require those
things, which I think was your original point. Anything which uses the
Oracle native driver (Python's cx_Oracle, Perl's DBD:Oracle, etc.) needs
these things, which makes setting them up more complicated. 

The fact is that Oracle chose to write a pure-Java implementation of
their driver which is really easy to install (although it might have
some limitations) but they did no such thing for other languages - plus
their license terms make it hard to bundle their driver, so everybody
needs to go through the "install instantclient, configure instantclient,
install language-specific drivers" dance (which btw is much easier now
than it was before instantclient)

So that's the answer to your question: Because Oracle made it so.

> On Tue, 21 May 2019 at 03:42, Chris Angelico <rosuav at gmail.com> wrote:
> > From the sound of things, the choice of database back end has
> > already been made, and the Python script just has to cope.
> > Otherwise, PostgreSQL would be an entirely better alternative.
> >
> 
> Yes it's that the problem.
> Well I love Postgres, but IMHO the big disadvantages over Oracle are two:
> BLOBs and performance.

Interesting. I think PostgreSQL's bytea type is much easier to work with
than Oracle's BLOBs, and they cover my needs (they have a 1 GB size
limit, but so far I haven't run into that). PostgreSQL also has LOs,
which seem to be even more awkward to use than Oracle's BLOBs, but I
haven't actually used them so I might be wrong.

And over the years I got the impression that PostgreSQL's performance is
at least comparable to that of Oracle - at least for "normal" databases,
not something like RAC (which I never used because we couldn't afford
it anyway). One of our databases was recently migrated to PostgreSQL and
the guy who mostly works with it was quite enthusiastic about the speed
(but there might have been other changes like new hardware ...).


> On Tue, 21 May 2019 at 15:14, Paul Moore <p.f.moore at gmail.com> wrote:
> > Because a commercial product like Oracle doesn't document
> > those protocols, open-source reimplementations are hard, if not
> > impossible.
> >
> 
> IMHO this is the more logical answer to my doubts.

Oracle is also well-known for employing an army of lawyers, so the
technical difficulties might just be the beginning.

[...]

> On Sun, 26 May 2019 at 19:53, Christian Gollwitzer <auriocus at gmx.de> wrote:
> > Python closer to the metal than Java? This is nonsense.
> >
> 
> Well, it seems to me the majority of python db drivers uses Cython,
> Python C API or external C libraries.

Which I would take as an indication that Python is "further from the
metal". Python isn't really suited for the job so you have to switch to
a lower-level (closer to the metal) language to implement it.

> So in this particular case Python *could* be more performant than
> Java.

Performance is only very indirectly related to being close to the metal.

        hp

-- 
   _  | Peter J. Holzer    | we build much bigger, better disasters now
|_|_) |                    | because we have much more sophisticated
| |   | hjp at hjp.at         | management tools.
__/   | http://www.hjp.at/ | -- Ross Anderson <https://www.edge.org/>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/python-list/attachments/20190616/2471bd7b/attachment.sig>