Thread: JDBC3 Sugquestion
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
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 > >
----- 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 > > > > > > >