|
From: Ken K. <kk...@kk...> - 2003-06-03 15:28:09
|
On Friday, I was working on an HSQL version of the incrementer but had
not completed the work before leaving for an extended holiday. I was
intending to use it so as to provide support in the Petclinic demo for
both Mysql and Hsql. I was pleased to find it done when I got back :=).
I have built the demo using both db's now and the insert use case works
well on both versions.
I would like to propose a bit of refactoring to the incrementers class
hierarchy to enhance pluggability. As it stands now, there is a lot of
common functionality that is redundant in the concrete classes and could
be pushed up to the AbstractDataFieldMaxValueIncrementer class:
1. cacheSize field and setter
2. prefixWithZero field and setter
3. dataSource field and setter
4. sequenceName (Oracle) or tableName (Mysql and Hsql) field and setter,
perhaps renamed to incrementerName
NOTE: The interface for RdmsMaxValueIncrementer is inconsistent with the
others and out-of-date. As it is also unsafe, perhaps it should be
removed altogether. It should at least be brought up-to-date.
I have provided an example to show how these changes can benefit the
user (developer):
In Petclinic, I provide beans in applicationContext.xml to configure the
dataSource and incrementer for my DAO bean. At present, I only have 1
insert use case, addVisit.
NOTE: I have elected to show the use of pooled datasources in a later
iteration of the demo.
For mysql:
<bean name="dataSource"
class="com.interface21.jdbc.datasource.DriverManagerDataSource" >
<property name="driverClassName">com.mysql.jdbc.Driver</property>
<property name="url">jdbc:mysql://localhost:3306/petclinic</property>
<property name="username">pc</property>
<property name="password">pc</property>
</bean>
<bean name="visitIncrementer"
class="com.interface21.jdbc.core.support.MySQLMaxValueIncrementer" >
<property name="dataSource" beanRef="true">dataSource</property>
<property name="tableName">visits_seq</property>
<property name="columnName">seq</property>
</bean>
For hsql:
<bean name="dataSource"
class="com.interface21.jdbc.datasource.DriverManagerDataSource" >
<property name="driverClassName">org.hsqldb.jdbcDriver</property>
<property name="url">jdbc:hsqldb:hsql://localhost:9001</property>
<property name="username">sa</property>
</bean>
<bean name="visitIncrementer"
class="com.interface21.jdbc.core.support.HsqlMaxValueIncrementer" >
<property name="dataSource" beanRef="true">dataSource</property>
<property name="tableName">visits_seq</property>
</bean>
My DAO bean:
<bean name="clinicDAO" class="petclinic.dao.ClinicJdbcDAO" >
<property name="dataSource" beanRef="true">dataSource</property>
<property name="visitIncrementer"
beanRef="true">visitIncrementer</property>
</bean>
As it stands, I need to configure a separate incrementer bean for each
new insert use case and add a field and setter for each one to the DAO
or alternatively embed code using the specific concrete class names in
the DAO which is now generic JDBC.
What I would like to do is something like this:
<bean name="incrementer"
singleton="false"
class="com.interface21.jdbc.core.support.MySQLMaxValueIncrementer" >
<!-- or some other concrete incrementer -->
<property name="dataSource" beanRef="true">dataSource</property>
</bean>
<bean name="clinicDAO" class="petclinic.dao.ClinicJdbcDAO" >
<property name="dataSource" beanRef="true">dataSource</property>
<property name="incrementer" beanRef="true">incrementer</property>
</bean>
I could then use this as a prototype bean for each of the insert use
cases which would then instantiate a prototype object using getBean() on
an AbstractDataFieldMaxValueIncrementer reference, subsequently setting
the incrementerName property for that object for the particular use case
in code. The code remains completely generic and all the database
configuration/selection is done in xml. A problem remains with the Mysql
version in that the columnName property needs to be set. This could be
accomplished without breaking genericity by conventionally using a
default columnName, such as "seq".
What do you think ???
Ken
|
|
From: <tri...@tr...> - 2003-06-03 15:45:47
|
Ken: Good points. > I would like to propose a bit of refactoring to the incrementers class > hierarchy to enhance pluggability. As it stands now, there is a lot of > common functionality that is redundant in the concrete classes and could > be pushed up to the AbstractDataFieldMaxValueIncrementer class: > > 1. cacheSize field and setter > 2. prefixWithZero field and setter > 3. dataSource field and setter > 4. sequenceName (Oracle) or tableName (Mysql and Hsql) field and setter, > perhaps renamed to incrementerName > I think it is a good idea to enhance the pluggability for these implementations. What we need to be able to set is Data Source, Sequence/Table Name and Column Name. When Column Nam is not needed, we could just leave it as null. If we use a standard name for the column, then it would be harder to use our framework on already existing databases that use a sequenece table. I believe the way we are doing it for MySQL is a fairly standard approach that is already used by many developers. > NOTE: The interface for RdmsMaxValueIncrementer is inconsistent with the > others and out-of-date. As it is also unsafe, perhaps it should be > removed altogether. It should at least be brought up-to-date. > I would vote for removing it. --Thomas |
|
From: JP P. <jp....@ti...> - 2003-06-03 20:31:50
|
Hi Ken,
I am always for avoiding duplicate code and pluggability is also
important, even more.
So I am globally for these works.
The last point: "column name" from MySql is a quite different.=20
If we compare the strategies on Oracle, HSql and MySql, we can see that
MySql is the only one allowing the assembling of many identifiers in the
same table.=20
Fixing the column name for MySql will put it back to the "shared"
possibilities, and having so a more homegeneous abstract view, indeed
more pluggable.
But making so, MySql users will no longer be able to put all the
incrementers in the same table due uniquely on other databases
possibilities.
As an alternative, why not add the "column name" in the
AbstractDataField... Setting the value for other databases having no
effect, having just an unusable feature.
I will not be impacted personaly at all, as I use only one Incrementer
for the whole database, having identities unique in the database. So I
am not dependant of object/relational mapping strategies. But inserting
data out of the application is more difficult. Typically, I have to use
such scenarios:
>update ach2_identites set nextval =3D LAST_INSERT_ID(nextval+1);
>SET @id=3DLAST_INSERT_ID();
>INSERT INTO ach2_typescolisage VALUES (@id,'PCE',1);
>
>update ach2_identites set nextval =3D LAST_INSERT_ID(nextval+1);
>SET @locid=3DLAST_INSERT_ID();
>INSERT INTO ach2_typescolisage_loc VALUES (@locid,@id,'fr','la
pi=E8ce','les {0} pi=E8ces',1);
So, if Isabelle agree to your last proposal, why not finally.
Jean-Pierre
> -----Message d'origine-----
> De : Ken Krebs [mailto:kk...@kk...]=20
> Envoy=E9 : mardi 3 juin 2003 17:23
> =C0 : tri...@tr...; jp....@ti...; Isabelle Muszynski
> Cc : 'spring-dev-list'
> Objet : [Springframework-developer] JDBC Insert functionality
>=20
>=20
> On Friday, I was working on an HSQL version of the=20
> incrementer but had=20
> not completed the work before leaving for an extended holiday. I was=20
> intending to use it so as to provide support in the Petclinic=20
> demo for=20
> both Mysql and Hsql. I was pleased to find it done when I got=20
> back :=3D).=20
> I have built the demo using both db's now and the insert use=20
> case works=20
> well on both versions.
>=20
> I would like to propose a bit of refactoring to the=20
> incrementers class=20
> hierarchy to enhance pluggability. As it stands now, there is=20
> a lot of=20
> common functionality that is redundant in the concrete=20
> classes and could=20
> be pushed up to the AbstractDataFieldMaxValueIncrementer class:
>=20
> 1. cacheSize field and setter
> 2. prefixWithZero field and setter
> 3. dataSource field and setter
> 4. sequenceName (Oracle) or tableName (Mysql and Hsql) field=20
> and setter,=20
> perhaps renamed to incrementerName
>=20
> NOTE: The interface for RdmsMaxValueIncrementer is=20
> inconsistent with the=20
> others and out-of-date. As it is also unsafe, perhaps it should be=20
> removed altogether. It should at least be brought up-to-date.
>=20
>=20
> I have provided an example to show how these changes can benefit the=20
> user (developer):
>=20
>=20
> In Petclinic, I provide beans in applicationContext.xml to=20
> configure the=20
> dataSource and incrementer for my DAO bean. At present, I only have 1=20
> insert use case, addVisit.
>=20
> NOTE: I have elected to show the use of pooled datasources in a later=20
> iteration of the demo.
>=20
>=20
> For mysql:
>=20
> <bean name=3D"dataSource"=20
> class=3D"com.interface21.jdbc.datasource.DriverManagerDataSource" >
> <property =
name=3D"driverClassName">com.mysql.jdbc.Driver</property>
> <property=20
> name=3D"url">jdbc:mysql://localhost:3306/petclinic</property>
> <property name=3D"username">pc</property>
> <property name=3D"password">pc</property>
> </bean>
> =20
> <bean name=3D"visitIncrementer"=20
> class=3D"com.interface21.jdbc.core.support.MySQLMaxValueIncrementer" >
> <property name=3D"dataSource" =
beanRef=3D"true">dataSource</property>
> <property name=3D"tableName">visits_seq</property>
> <property name=3D"columnName">seq</property>
> </bean>
>=20
> =20
> For hsql:
>=20
> <bean name=3D"dataSource"=20
> class=3D"com.interface21.jdbc.datasource.DriverManagerDataSource" >
> <property =
name=3D"driverClassName">org.hsqldb.jdbcDriver</property>
> <property =
name=3D"url">jdbc:hsqldb:hsql://localhost:9001</property>
> <property name=3D"username">sa</property>
> </bean>
> =20
> <bean name=3D"visitIncrementer"=20
> class=3D"com.interface21.jdbc.core.support.HsqlMaxValueIncrementer" >
> <property name=3D"dataSource" =
beanRef=3D"true">dataSource</property>
> <property name=3D"tableName">visits_seq</property>
> </bean>
>=20
>=20
> My DAO bean:
>=20
> <bean name=3D"clinicDAO" class=3D"petclinic.dao.ClinicJdbcDAO" >
> <property name=3D"dataSource" =
beanRef=3D"true">dataSource</property>
> <property name=3D"visitIncrementer"=20
> beanRef=3D"true">visitIncrementer</property>
> </bean>
> =20
>=20
>=20
> As it stands, I need to configure a separate incrementer bean=20
> for each=20
> new insert use case and add a field and setter for each one=20
> to the DAO=20
> or alternatively embed code using the specific concrete class=20
> names in=20
> the DAO which is now generic JDBC.
>=20
>=20
> What I would like to do is something like this:
>=20
> <bean name=3D"incrementer"
> singleton=3D"false"
> =20
> class=3D"com.interface21.jdbc.core.support.MySQLMaxValueIncrementer" > =
> <!-- or some other concrete incrementer -->
> <property name=3D"dataSource" =
beanRef=3D"true">dataSource</property>
> </bean>
> =20
> <bean name=3D"clinicDAO" class=3D"petclinic.dao.ClinicJdbcDAO" >
> <property name=3D"dataSource" =
beanRef=3D"true">dataSource</property>
> <property name=3D"incrementer" =
beanRef=3D"true">incrementer</property>
> </bean>
> =20
> =20
> I could then use this as a prototype bean for each of the insert use=20
> cases which would then instantiate a prototype object using=20
> getBean() on=20
> an AbstractDataFieldMaxValueIncrementer reference,=20
> subsequently setting=20
> the incrementerName property for that object for the=20
> particular use case=20
> in code. The code remains completely generic and all the database=20
> configuration/selection is done in xml. A problem remains=20
> with the Mysql=20
> version in that the columnName property needs to be set. This=20
> could be=20
> accomplished without breaking genericity by conventionally using a=20
> default columnName, such as "seq".
>=20
>=20
>=20
> What do you think ???
>=20
>=20
> Ken
>=20
>=20
>=20
>=20
>=20
>=20
>=20
>=20
>=20
>=20
>=20
>=20
>=20
>=20
>=20
>=20
>=20
>=20
>=20
>=20
>=20
>=20
|
|
From: Ken K. <kk...@kk...> - 2003-06-05 21:51:03
|
Since there seems to be a consensus in favor, I would like to go ahead and make these changes if there are no objections, also adding columnName to AbstractDataFieldMaxValueIncrementer and removing the RdmsMaxValueIncrementer class. As I don't have commit rights, someone will have to assist me or I will need to get those rights. Ken Ken Krebs wrote: > On Friday, I was working on an HSQL version of the incrementer but had > not completed the work before leaving for an extended holiday. I was > intending to use it so as to provide support in the Petclinic demo for > both Mysql and Hsql. I was pleased to find it done when I got back > :=). I have built the demo using both db's now and the insert use case > works well on both versions. > > I would like to propose a bit of refactoring to the incrementers class > hierarchy to enhance pluggability. As it stands now, there is a lot of > common functionality that is redundant in the concrete classes and > could be pushed up to the AbstractDataFieldMaxValueIncrementer class: > > 1. cacheSize field and setter > 2. prefixWithZero field and setter > 3. dataSource field and setter > 4. sequenceName (Oracle) or tableName (Mysql and Hsql) field and > setter, perhaps renamed to incrementerName > > NOTE: The interface for RdmsMaxValueIncrementer is inconsistent with > the others and out-of-date. As it is also unsafe, perhaps it should be > removed altogether. It should at least be brought up-to-date. > > > I have provided an example to show how these changes can benefit the > user (developer): > > > In Petclinic, I provide beans in applicationContext.xml to configure > the dataSource and incrementer for my DAO bean. At present, I only > have 1 insert use case, addVisit. > > NOTE: I have elected to show the use of pooled datasources in a later > iteration of the demo. > > > For mysql: > > <bean name="dataSource" > class="com.interface21.jdbc.datasource.DriverManagerDataSource" > > <property name="driverClassName">com.mysql.jdbc.Driver</property> > <property name="url">jdbc:mysql://localhost:3306/petclinic</property> > <property name="username">pc</property> > <property name="password">pc</property> > </bean> > <bean name="visitIncrementer" > class="com.interface21.jdbc.core.support.MySQLMaxValueIncrementer" > > <property name="dataSource" beanRef="true">dataSource</property> > <property name="tableName">visits_seq</property> > <property name="columnName">seq</property> > </bean> > > > For hsql: > > <bean name="dataSource" > class="com.interface21.jdbc.datasource.DriverManagerDataSource" > > <property name="driverClassName">org.hsqldb.jdbcDriver</property> > <property name="url">jdbc:hsqldb:hsql://localhost:9001</property> > <property name="username">sa</property> > </bean> > <bean name="visitIncrementer" > class="com.interface21.jdbc.core.support.HsqlMaxValueIncrementer" > > <property name="dataSource" beanRef="true">dataSource</property> > <property name="tableName">visits_seq</property> > </bean> > > > My DAO bean: > > <bean name="clinicDAO" class="petclinic.dao.ClinicJdbcDAO" > > <property name="dataSource" beanRef="true">dataSource</property> > <property name="visitIncrementer" > beanRef="true">visitIncrementer</property> > </bean> > > > As it stands, I need to configure a separate incrementer bean for each > new insert use case and add a field and setter for each one to the DAO > or alternatively embed code using the specific concrete class names in > the DAO which is now generic JDBC. > > > What I would like to do is something like this: > > <bean name="incrementer" > singleton="false" > > class="com.interface21.jdbc.core.support.MySQLMaxValueIncrementer" > > <!-- or some other concrete incrementer --> > <property name="dataSource" beanRef="true">dataSource</property> > </bean> > > <bean name="clinicDAO" class="petclinic.dao.ClinicJdbcDAO" > > <property name="dataSource" beanRef="true">dataSource</property> > <property name="incrementer" beanRef="true">incrementer</property> > </bean> > > I could then use this as a prototype bean for each of the insert use > cases which would then instantiate a prototype object using getBean() > on an AbstractDataFieldMaxValueIncrementer reference, subsequently > setting the incrementerName property for that object for the > particular use case in code. The code remains completely generic and > all the database configuration/selection is done in xml. A problem > remains with the Mysql version in that the columnName property needs > to be set. This could be accomplished without breaking genericity by > conventionally using a default columnName, such as "seq". > > > > What do you think ??? > > > Ken > > > > > > > > > > > > > > > > > > > > > > > > ------------------------------------------------------- > This SF.net email is sponsored by: eBay > Get office equipment for less on eBay! > http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5 > _______________________________________________ > Springframework-developer mailing list > Spr...@li... > https://lists.sourceforge.net/lists/listinfo/springframework-developer > > |