Maybe I won't understand what you are trying to do until I see the code,
but I still don't get it.

I only see a point in making an abstract class with a concrete subclass if
there is going to be more than one subclass. Are you planning another
Connection implementation? If so, what will it do?

What exactly is clearer with more classes and packages?

I will mention that my original plan was to try to create a Connection that
implemented both java.sql.Connection and javax.resource.cci.Connection:
that is why there is a jdbc package. This turned out to be impossible due
to method signature conflicts. Since then I have been meaning to move
everything in jdbc into jca so the methods that should be package access
are able to be package access. So, I really don't understand why you want
to make an additional package.

The refactoring I was talking about with data type objects is not in
support of additional functionality, I just think it is a clearer design
and simpler.

david jencks

On 2002.05.20 21:15:08 -0400 Blas Rodriguez Somoza wrote:
> Hello
>
> Let me give some answers.
>
> First, I have to make clear that the proposal is not a complete
> refactoring, but only to split the jdbc package into two new
> packages to separate two diferent kind of functions in the jdbc package
> of the driver. It does not affect other packages in the
> driver (jca, gds or jgds).
>
> Second, I did all the changes and create a working driver. The
> modified driver pass all the tests (excluding the
> poolManagerConnection that also fails before the changes).
>
> Third, my intention with this changes is to improve clearness in the
> driver, and thus make the work easier. I propose these
> changes because it is very easy to do it now and helps to improve the
> separation between layers in the driver. I expect to continue
> working on the core JDBC layer of the driver and I need a clearer
> architecture.
>
> During my work on the driver JDBC support, I make some cleaning on
> the area I'm working with, basic jdbc, and thus the changes
> are simpler now. I use FBConnection as a proxie to connect jca and basic
> jdbc.
>
> The changes needed to implement the proposal are only the following
>
> - Create package basicjdbc.
> - Move some driver classes and tests from jdbc to basicjdbc.
> - Create FBAbstractConnection and FBAbstractConnectionHelper in
> basicjdbc from the classes in jdbc and make FBConnection and
> FBConnectionHelper in jdbc extends the abstract classes. I ommit the list
> of the methods that implements each class.
> - For the classes in basicjdbc substitute FBConnection with
> FBAbstractConnection
> and FBConnectionHelper with FBAbstractConnectionHelper.
> - For classes in jca and jdbc sustitute
> org.firebirdsql.jdbc.FBStatement with
> org.firebirdsql.basicjdbc.FBStatement.
>
> David, you say in a previous e-mail that you are thinking about a
> refactoring of the data types to implement new functions or
> enhance existing ones. To begin a new work you think in refactoring, that
> is the same I think, first clean, then create.
>
> Regards
> Blas Rodriguez Somoza
>
>
> ----- Original Message -----
> From: "David Jencks" <davidjencks@...>
> To: <Firebird-Java@yahoogroups.com>
> Sent: Monday, May 20, 2002 8:44 PM
> Subject: Re: [Firebird-Java] Re: Jdbc 2.0 Patches
>
>
> > I will try to look at this soon but can't promise anything. However,
> from
> > glancing quickly at your posts I don't understand what the motivation
> is
> > for these changes. Could you explain again why you want to make these
> > changes?
> >
> > Many thanks for the improvements you already committed!
> >
> > david jencks
> >
> >
> > On 2002.05.20 13:51:53 -0400 Blas Rodriguez Somoza wrote:
> > > Hello Roman
> > >
> > > I employ two more hours, finishing the work and testing the
> result,
> > > and I have now a working Driver with the proposal
> > > implemented and tested. So I need only oppinions/votes but no work.
> :-)
> > >
> > > The final package distribution is slightly different. I don't
> > > subclass statement classes because it is too complex and perhaps
> > > the wrong design choice. Whether it is clear why Connection must be
> > > subclassed, it is not clear for Statements.
> > >
> > > The AbstractConnection defines some abstract transaction methods,
> > > Statements does not need to implement transaction logic but
> > > only use the AbstractConnection methods. Finally I only subclass
> > > Connection and ConnectionHelper.
> > >
> > > The dependencies are the following
> > >
> > > - basicjdbc don't depend on firebirdsql.jca, firebirdsql.jdbc or
> > > javax.resource
> > > - jdbc dependencies on basicjdbc.
> > > FBConnection EXTENDS org.firebirdsql.basicjdbc.FBAbstractConnection
> > > FBConnectionHelper EXTENDS org.firebirdsql.basicjdbc.FBAbstractConnectionHelper
> > > FBConnection USES org.firebirdsql.basicjdbc.FBStatement
> > > - jca dependencies on basicjdbc.
> > > FBManagedConnection USES org.firebirdsql.basicjdbc.FBStatement
> > > FBManagedConnectionFactory USES org.firebirdsql.basicjdbc.FBStatement
> > > - jca and jdbc has several depencies as do now.
> > >
> > > All the internal and external tests passed OK excluded
> PoolingManager
> > > test, as happen before.
> > >
> > > Regards
> > > Blas Rodriguez Somoza
> > >
> > > ----- Original Message -----
> > > From: "rrokytskyy" <rrokytskyy@...>
> > > To: <Firebird-Java@yahoogroups.com>
> > > Sent: Monday, May 20, 2002 5:00 PM
> > > Subject: [Firebird-Java] Re: Jdbc 2.0 Patches
> > >
> > >
> > > > Hi,
> > > >
> > > > > There is one proposal I want to make before the next beta was
> > > > > delivered, mainly because I have done the work to implement it on
> > > > > my local CVS copy. I'm now sending the proposal to the list. I
> > > > > think that with this proposal will be easier for an average user
> to
> > > > > understand and patch the driver, and doing so help in the
> > > > > development.
> > > >
> > > > Are you talking about your restructuring proposal? I will think
> about
> > > > it, but such refactoring requires a lot of time. I pretty sure that
> > > > we have to do refactoring sooner or later. But currently I hardly
> can
> > > > help you in this effort until end of June, maybe July. Also we need
> > > > support from David and Alejandro (I'm simply afraid to change
> > > > anything in jca, gds and jgds packages).
> > > >
> > > > David? Alejandro? Your comments?
> > > >
> > > > > Also I want to test the get/set methods before the final
> > > > > version but I don't know how many betas will be delivered. The
> tests
> > > > > and patches will take some time and it is better to wait for the
> > > > > beta 3.
> > > >
> > > > I think there will be more than 3 beta. Or 2 beta + more than one
> > > > release candidate :) There are some big open issues that should be
> > > > addressed, like driver performance, better callable statement
> > > > support, etc. So, I would prefer to stay in endless beta that is
> > > > stable than to release unstable version.
> > > >
> > > > > Finally I must commit a little document about JDBC support,
> > > > > but I will do it today.
> > > >
> > > > Documentation is something we're definitely missing here... Thanks
> a
> > > > lot!
> > > >
> > > > Best regards,
> > > > Roman Rokytskyy
> > > >
> > > >
> > > >
> > > > To unsubscribe from this group, send an email to:
> > > > Firebird-Java-unsubscribe@yahoogroups.com
> > > >
> > > >
> > > >
> > > > Your use of Yahoo! Groups is subject to
> > > http://docs.yahoo.com/info/terms/
> > > >
> > > >
> > > >
> > >
> > >
> > >
> > > To unsubscribe from this group, send an email to:
> > > Firebird-Java-unsubscribe@yahoogroups.com
> > >
> > >
> > >
> > > Your use of Yahoo! Groups is subject to
> http://docs.yahoo.com/info/terms/
> > >
> > >
> > >
> > >
> > >
> >
> >
> > To unsubscribe from this group, send an email to:
> > Firebird-Java-unsubscribe@yahoogroups.com
> >
> >
> >
> > Your use of Yahoo! Groups is subject to
> http://docs.yahoo.com/info/terms/
> >
> >
> >
>
>
>
>
>
> To unsubscribe from this group, send an email to:
> Firebird-Java-unsubscribe@yahoogroups.com
>
>
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
>
>
>
>
>