Thread: JDBC3 Sugquestion

JDBC3 Sugquestion

From
"Ian Brandt"
Date:
Hi,

I am interested in JDBC3 support for PostgreSQL.  I was going through the
archived posts with regard to this, and have a half suggestion, half
question (hence the new word I just made up in the subject)...

Instead of the previously suggested code forking, build process changing,
and RTTI related ideas, would it be possible to address the problem of
supporting multiple JDBC versions with source control?  Here's a rough idea
of how this might work (born out of much ignorance with regard to your
development practices!)...

Create a new CVS repository for JDBC.  Take the existing code, extract and
rework everything such as to make a JDBC1 compliant implementation.  This
would involve some re-packaging.  Everything JDBC related that is currently
under org.postgresql would be moved one level deeper to org.postgresql.jdbc,
except for the stuff currently under org.postgresql.jdbc1, which would be
moved/merged to also be in org.postgresql.jdbc.  Once everything is reworked
and checked in, create a jdbc1 branch.  Then take the stuff currently in the
org.postgresql.jdbc2 package, and rework that into org.postgresql.jdbc in
this new repository as well, so to have a JDBC2 compliant implementation.
Create a jdbc2 branch.

Updating to JDBC3,4,etc. would then involve updating the existing code to be
compliant, and creating a new branch.  The driver would be distributed as
pgjdbc1.jar, pgjdbc2.jar, etc. simply by checking out the corresponding
branch, building under the appropriate jdk, and jar'ing it up.  Bug fixes
could be done in the lowest appropriate branch, and merged forward as
appropriate.

As far as users are concerned, having to use the different jar and classpath
based on the JDK/JDBC version they desire to use shouldn't be an issue.
This is very commonplace for such things.

So I hope this idea isn't totally out in left field!  Either way I look
forward to JDBC3 support.

Thanks,

Ian


Re: JDBC3 Sugquestion

From
Barry Lind
Date:
Ian,

There are three reasons why I think what you are suggesting doesn't work
as well as some other suggestions that have been made.

1)  Your proposal essentially creates three distinct copies of the code,
one in each of three cvs branches.  This means that when a bug needs to
be fixed, then the same fix needs to be done three times.  What is
really desired is a good OO way of encapsulating the common code and
having differences only where necessary.

2)  How would the source code under your proposal be bundled?  Given
that source code for open source software if very important, how would
the pgsql-src.tar.gz file be produced?  It seems difficult to get files
from multiple different branches but with the same names pulled and
built into a common source distribution.

3)  How would you suggest branches on these branches be done?  For
example now that 7.3 development is opened up, there is a 7.2 branch on
the source to facilitate bugs going into 7.2.x.  How would you suggest
these release branches be layered on top of your proposed branches
without causing too much confusion?

thanks,
--Barry


Ian Brandt wrote:
> Hi,
>
> I am interested in JDBC3 support for PostgreSQL.  I was going through the
> archived posts with regard to this, and have a half suggestion, half
> question (hence the new word I just made up in the subject)...
>
> Instead of the previously suggested code forking, build process changing,
> and RTTI related ideas, would it be possible to address the problem of
> supporting multiple JDBC versions with source control?  Here's a rough idea
> of how this might work (born out of much ignorance with regard to your
> development practices!)...
>
> Create a new CVS repository for JDBC.  Take the existing code, extract and
> rework everything such as to make a JDBC1 compliant implementation.  This
> would involve some re-packaging.  Everything JDBC related that is currently
> under org.postgresql would be moved one level deeper to org.postgresql.jdbc,
> except for the stuff currently under org.postgresql.jdbc1, which would be
> moved/merged to also be in org.postgresql.jdbc.  Once everything is reworked
> and checked in, create a jdbc1 branch.  Then take the stuff currently in the
> org.postgresql.jdbc2 package, and rework that into org.postgresql.jdbc in
> this new repository as well, so to have a JDBC2 compliant implementation.
> Create a jdbc2 branch.
>
> Updating to JDBC3,4,etc. would then involve updating the existing code to be
> compliant, and creating a new branch.  The driver would be distributed as
> pgjdbc1.jar, pgjdbc2.jar, etc. simply by checking out the corresponding
> branch, building under the appropriate jdk, and jar'ing it up.  Bug fixes
> could be done in the lowest appropriate branch, and merged forward as
> appropriate.
>
> As far as users are concerned, having to use the different jar and classpath
> based on the JDK/JDBC version they desire to use shouldn't be an issue.
> This is very commonplace for such things.
>
> So I hope this idea isn't totally out in left field!  Either way I look
> forward to JDBC3 support.
>
> Thanks,
>
> Ian
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 1: subscribe and unsubscribe commands go to majordomo@postgresql.org
>
>



Re: JDBC3 Sugquestion

From
"Ian Brandt"
Date:
----- Original Message -----
From: "Barry Lind" <barry@xythos.com>
To: "Ian Brandt" <ian@ianbrandt.com>
Cc: "PostgreSQL JDBC" <pgsql-jdbc@postgresql.org>
Sent: Monday, February 18, 2002 12:53 PM
Subject: Re: [JDBC] JDBC3 Sugquestion


> Ian,
>
> There are three reasons why I think what you are suggesting doesn't work
> as well as some other suggestions that have been made.
>
> 1)  Your proposal essentially creates three distinct copies of the code,
> one in each of three cvs branches.  This means that when a bug needs to
> be fixed, then the same fix needs to be done three times.  What is
> really desired is a good OO way of encapsulating the common code and
> having differences only where necessary.

Sorry, I've been using SCCS for the past three years, and I mixed up my CVS
terminology.  I meant to say "tag" instead of "branch".  Creating copies of
the code is exactly what I was hoping could be avoided.  Instead
JDBC1,2,3,etc. would be handled by making successive releases of the same
code.  And again bug fixes would be done in the lowest applicable revision,
and merged forward as appropriate.  Hopefully this clears things up a good
bit?

Ian



> 2)  How would the source code under your proposal be bundled?  Given
> that source code for open source software if very important, how would
> the pgsql-src.tar.gz file be produced?  It seems difficult to get files
> from multiple different branches but with the same names pulled and
> built into a common source distribution.
>
> 3)  How would you suggest branches on these branches be done?  For
> example now that 7.3 development is opened up, there is a 7.2 branch on
> the source to facilitate bugs going into 7.2.x.  How would you suggest
> these release branches be layered on top of your proposed branches
> without causing too much confusion?
>
> thanks,
> --Barry
>
>
> Ian Brandt wrote:
> > Hi,
> >
> > I am interested in JDBC3 support for PostgreSQL.  I was going through
the
> > archived posts with regard to this, and have a half suggestion, half
> > question (hence the new word I just made up in the subject)...
> >
> > Instead of the previously suggested code forking, build process
changing,
> > and RTTI related ideas, would it be possible to address the problem of
> > supporting multiple JDBC versions with source control?  Here's a rough
idea
> > of how this might work (born out of much ignorance with regard to your
> > development practices!)...
> >
> > Create a new CVS repository for JDBC.  Take the existing code, extract
and
> > rework everything such as to make a JDBC1 compliant implementation.
This
> > would involve some re-packaging.  Everything JDBC related that is
currently
> > under org.postgresql would be moved one level deeper to
org.postgresql.jdbc,
> > except for the stuff currently under org.postgresql.jdbc1, which would
be
> > moved/merged to also be in org.postgresql.jdbc.  Once everything is
reworked
> > and checked in, create a jdbc1 branch.  Then take the stuff currently in
the
> > org.postgresql.jdbc2 package, and rework that into org.postgresql.jdbc
in
> > this new repository as well, so to have a JDBC2 compliant
implementation.
> > Create a jdbc2 branch.
> >
> > Updating to JDBC3,4,etc. would then involve updating the existing code
to be
> > compliant, and creating a new branch.  The driver would be distributed
as
> > pgjdbc1.jar, pgjdbc2.jar, etc. simply by checking out the corresponding
> > branch, building under the appropriate jdk, and jar'ing it up.  Bug
fixes
> > could be done in the lowest appropriate branch, and merged forward as
> > appropriate.
> >
> > As far as users are concerned, having to use the different jar and
classpath
> > based on the JDK/JDBC version they desire to use shouldn't be an issue.
> > This is very commonplace for such things.
> >
> > So I hope this idea isn't totally out in left field!  Either way I look
> > forward to JDBC3 support.
> >
> > Thanks,
> >
> > Ian
> >
> >
> > ---------------------------(end of broadcast)---------------------------
> > TIP 1: subscribe and unsubscribe commands go to majordomo@postgresql.org
> >
> >
>
>
>