agora inbox for pljava-dev@postgresql.org
help / color / mirror / Atom feed[Pljava-dev] postgresql jdbc driver
3+ messages / 0 participants
[nested] [flat]
* [Pljava-dev] postgresql jdbc driver
@ 2005-02-24 18:45
2005-02-24 19:26 ` [Pljava-dev] postgresql jdbc driver
2005-02-24 20:03 ` [Pljava-dev] Re: postgresql jdbc driver
0 siblings, 2 replies; 3+ messages in thread
From: @ 2005-02-24 18:45 UTC (permalink / raw)
Hi Thomas
I asked the person working on Compiere with PLJava the following:
The PLJava web site says it comes with:
"An embedded, high performance, JDBC driver utilizing the internal
PostgreSQL SPI routines."
So why do you also need the jdbc3-810 driver?
His answer:
Yes, I know PLJAVA has a JDBC Native, the main problem is
Compiere 252 has the following requirements:
# Full support of ANSI SQL 99 (CASE, all JOIN types, ..)
# Support of Views and Views on Views
# Support of User Defined Functions
(preferably via SQLJ - Java running in the database)
# Inline Views (e.g. SELECT ... FROM (SELECT xx FROM yy) ..)
# JDBC 3.0 Support (especially RowSet)
http://www.compiere.org/technology/database/index.html
Can you comment Thomas?
BTW, I noticed that the reply-to defaults to the senders email, not
pljava-dev at gborg.postgresql.org. So if you are not careful, not all
messages will be seen by everyone on the list.
=========================
Bart Bremmers, Gen. Mgr.
Craft-Bilt Materials Ltd.
Markham, Ontario
^ permalink raw reply [nested|flat] 3+ messages in thread
* [Pljava-dev] postgresql jdbc driver
2005-02-24 18:45 [Pljava-dev] postgresql jdbc driver
@ 2005-02-24 19:26 `
1 sibling, 0 replies; 3+ messages in thread
From: @ 2005-02-24 19:26 UTC (permalink / raw)
Bart Bremmers wrote:
> Hi Thomas
> I asked the person working on Compiere with PLJava the following:
>
> The PLJava web site says it comes with:
> "An embedded, high performance, JDBC driver utilizing the internal
> PostgreSQL SPI routines."
> So why do you also need the jdbc3-810 driver?
PLJava doesn't need a jdbc3-810 driver in itself. The deployer utility
and the example tester (both client programs) uses it. Both test and
deployment can also be done using psql. In fact, PLJava comes with two
scripts, install.sql and uninstall.sql for this purpose.
> His answer:
>
> Yes, I know PLJAVA has a JDBC Native, the main problem is
> Compiere 252 has the following requirements:
>
> # Full support of ANSI SQL 99 (CASE, all JOIN types, ..)
> # Support of Views and Views on Views
> # Support of User Defined Functions
> (preferably via SQLJ - Java running in the database)
> # Inline Views (e.g. SELECT ... FROM (SELECT xx FROM yy) ..)
> # JDBC 3.0 Support (especially RowSet)
>
> http://www.compiere.org/technology/database/index.html
>
> Can you comment Thomas?
None of the things you line up here are things that are of any concern
for the JDBC driver except the last one. The JDBC driver will pass SQL
statements to the backend more or less unaffected. The right thing to do
here is to look at how well the PostgreSQL backend meets those
requirements. I think most of SQL 99 is well covered as well as the view
related stuff. PLJava *is* "Java running in the database" so that
specific item is well covered :-)
SQLJ is far more then "Java running in the database" b.t.w. It consists
of three parts.
Part 0: Embedded SQL in Java
Part 1: SQL routines using Java
Part 2: SQL types using Java.
A good overview can be found here:
http://www.service-architecture.com/database/articles/sqlj.html
Part 0:, a fairly horrible concept that mangles Java code and produces
something that cannot be debugged has been abandoned by most, even
Oracle. Read more here:
http://otn.oracle.com/tech/java/sqlj_jdbc/pdf/oracle_sqlj_roadmap.pdf
PLJava has every intention of following the Part 1 and part 2 as closely
as possible.
The last item, the RowSet, is not applicable when you run inside of a
database. The RowSet is specifically designed to allow remote (and
disconnected) perusal of a ResultSet and is thus not at all applicable
to running inside of database functions.
PLJava certainly doesn't prevent you from using RowSet's if you really
want to of course. I just can't see the use-case where it would be
beneficial.
> BTW, I noticed that the reply-to defaults to the senders email, not
> pljava-dev at gborg.postgresql.org. So if you are not careful, not all
> messages will be seen by everyone on the list.
I'm not an expert in managing mailing lists. I do appreciate any advice
on how to improve the way it's set up.
Hope this helps,
Thomas Hallgren
^ permalink raw reply [nested|flat] 3+ messages in thread
* [Pljava-dev] Re: postgresql jdbc driver
2005-02-24 18:45 [Pljava-dev] postgresql jdbc driver
@ 2005-02-24 20:03 `
1 sibling, 0 replies; 3+ messages in thread
From: @ 2005-02-24 20:03 UTC (permalink / raw)
Bart,
> So why do you also need the jdbc3-810 driver?
>
I realize that I might have misread what you asked for. But if the
requirements that he listed was an answer to "why they use the jdbc3-810
driver as a complement (or instead of?) the PLJava driver", then his
answer just make no sense at all:
> # Full support of ANSI SQL 99 (CASE, all JOIN types, ..)
Neither of the JDBC drivers are concerned with this.
> # Support of Views and Views on Views
Neither of the JDBC drivers are concerned with this.
> # Support of User Defined Functions
> (preferably via SQLJ - Java running in the database)
PLJava *is* user defined functions and it's JDBC driver allows you to
call other JDBC driver functions through SQL. Neither of the JDBC
drivers are concerned with SQLJ.
> # Inline Views (e.g. SELECT ... FROM (SELECT xx FROM yy) ..)
> # JDBC 3.0 Support (especially RowSet)
>
As stated before, RowSet's just makes no sense at all in the PLJava
domain, i.e. inside of a user defined function running inside the
database backend.
A final note and I'm not at all sure it's in any way applicable:
Using the client jdbc driver inside of PLJava is a *very* bad idea since
it would result in a new remote connection to the backend and hence, not
only severely degraded performance but also a different transaction. The
PLJava jdbc driver runs within the transaction that was started by the
caller of the user defined function. Virtually everything will break if
your violate transaction boundaries.
Regards,
Thomas Hallgren
^ permalink raw reply [nested|flat] 3+ messages in thread
end of thread, other threads:[~2005-02-24 20:03 UTC | newest]
Thread overview: 3+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2005-02-24 18:45 [Pljava-dev] postgresql jdbc driver
2005-02-24 19:26 `
2005-02-24 20:03 `
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox