springframework-developer

RE: [Springframework-developer] DataFieldMaxValueIncrementer

[Dmitriy K. <dko...@ru...>]

Definitely +1 as I originally designed it with int, long and String... =
The
simpler the implemetation the better :-))

Regards,
Dmitriy.

-----Original Message-----
From: spr...@li...
[mailto:spr...@li...] On Behalf =
Of
j=FCrgen h=F6ller [werk3AT]
Sent: Wednesday, February 25, 2004 3:48 PM
To: spr...@li...
Subject: [Springframework-developer] DataFieldMaxValueIncrementer


I've added PostgreSQLSequenceMaxValueIncrementer today, as attached to =
our
JIRA. On the occasion, I've reviewed the incrementer implementations:
They're too complicated for what they achieve, IMO.Thus, I've dropped =
the
inner class NextMaxValueProviders and moved the code to the
DataFieldMaxValueIncrementer class hierarchy itself.
=20
I've noticed that AbstractDataFieldMaxValueIncrementer's nextDoubleValue
effectively returns an integer, like nextIntValue/nextLongValue - after =
all,
the template method getNextKey returns a long, so there's no chance for =
a
true double. Thus, I see no point in keeping the nextDoubleValue method =
in
the DataFieldMaxValueIncrementer interface; all current implementations =
do
not return doubles here.
=20
Furthermore, why does getNextKey take a type parameter when it returns a
long anyway? Any JDBC driver will let you read both an int and a long =
via
rs.getLong, so there's no point in that type parameter. Simply reading =
the
value via getLong should be sufficient.
=20
This leaves a very simple DataFieldMaxValueIncrementer interface with
nextIntValue, nextLongValue and nextStringValue methods, with
implementations that achieve their goal in a straightforward fashion.
AbstractDataFieldMaxValueIncrementer delegates all three to getNextKey =
which
returns a long, casting the long to an int respectively converting it to =
a
string with optional padding.
=20
This should still cover all current usages and therefore not break
compatibility, and it should make it as easy as possible to implement an
AbstractDataFieldMaxValueIncrementer subclass for a specific database.
Thomas, Dmitrity, what do you think?
=20
Juergen
=20
P.S.:
Obviously, 1.0 RC2 won't be released tonight but rather at the end of =
the
week. I believe it's worth it, as I'd also like to wait for feedback on =
the
other recent changes.
=20


-------------------------------------------------------
SF.Net is sponsored by: Speed Start Your Linux Apps Now.
Build and deploy apps & Web services for Linux with
a free DVD software kit from IBM. Click Now!
http://ads.osdn.com/?ad_id=1356&alloc_id438&op=3Dclick
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

Re: [Springframework-developer] DataFieldMaxValueIncrementer

[<jue...@we...>]

I'm done with the simplicication so far - less than half of the code =
remains ;-)
=20
However, there's still the value cache. I strongly doubt that this is a =
good idea, particularly with database sequences. Essentially, if the =
cache size is 10, we're accessing the sequence 10 times in advance =
instead of asking in whenever an id is requested. There's the same =
amount of SQL statements involved; what's the benefit here?
=20
The drawback is that we need to synchronize cache access for this. If we =
simply went straight to the database sequence for each id, we could =
delegate concurrency to the database. And I don't know of an O/R mapping =
tool that does such sequence value caching (please correct me if I'm =
wrong). All things considered, I suggest to drop the value cache =
completely.
=20
Juergen
=20

________________________________

Von: spr...@li... im Auftrag =
von tri...@tr...
Gesendet: Mi 25.02.2004 23:02
An: spr...@li...
Betreff: Re: [Springframework-developer] DataFieldMaxValueIncrementer




+1

I never understood the need for a double as an incrementer anyway.  =
Simple is
better.  The OracleSequenceMaxValueIncrementer could use some =
refactoring too.
We don't need a SqlFunction - we should be able to use the new =
queryForXxxx
methods on the JDBC Template.  Once you check in your changes, I can =
take a look
at the Oracle one.

Thomas

Quoting "j=FCrgen h=F6ller [werk3AT]" <jue...@we...>:

> I've added PostgreSQLSequenceMaxValueIncrementer today, as attached to =
=3D
> our JIRA. On the occasion, I've reviewed the incrementer =3D
> implementations: They're too complicated for what they achieve, =3D
> IMO.Thus, I've dropped the inner class NextMaxValueProviders and moved =
=3D
> the code to the DataFieldMaxValueIncrementer class hierarchy itself.
> =3D20
> I've noticed that AbstractDataFieldMaxValueIncrementer's =
nextDoubleValue =3D
> effectively returns an integer, like nextIntValue/nextLongValue - =
after =3D
> all, the template method getNextKey returns a long, so there's no =
chance =3D
> for a true double. Thus, I see no point in keeping the nextDoubleValue =
=3D
> method in the DataFieldMaxValueIncrementer interface; all current =3D
> implementations do not return doubles here.
> =3D20
> Furthermore, why does getNextKey take a type parameter when it returns =
a =3D
> long anyway? Any JDBC driver will let you read both an int and a long =
=3D
> via rs.getLong, so there's no point in that type parameter. Simply =3D
> reading the value via getLong should be sufficient.
> =3D20
> This leaves a very simple DataFieldMaxValueIncrementer interface with =
=3D
> nextIntValue, nextLongValue and nextStringValue methods, with =3D
> implementations that achieve their goal in a straightforward fashion. =
=3D
> AbstractDataFieldMaxValueIncrementer delegates all three to getNextKey =
=3D
> which returns a long, casting the long to an int respectively =
converting =3D
> it to a string with optional padding.
> =3D20
> This should still cover all current usages and therefore not break =3D
> compatibility, and it should make it as easy as possible to implement =
an =3D
> AbstractDataFieldMaxValueIncrementer subclass for a specific database. =
=3D
> Thomas, Dmitrity, what do you think?
> =3D20
> Juergen
> =3D20
> P.S.:
> Obviously, 1.0 RC2 won't be released tonight but rather at the end of =
=3D
> the week. I believe it's worth it, as I'd also like to wait for =
feedback =3D
> on the other recent changes.
> =3D20
>
>
> -------------------------------------------------------
> SF.Net is sponsored by: Speed Start Your Linux Apps Now.
> Build and deploy apps & Web services for Linux with
> a free DVD software kit from IBM. Click Now!
> http://ads.osdn.com/?ad_id=3D1356&alloc_id=3D3438&op=3Dclick
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>





-------------------------------------------------------
SF.Net is sponsored by: Speed Start Your Linux Apps Now.
Build and deploy apps & Web services for Linux with
a free DVD software kit from IBM. Click Now!
http://ads.osdn.com/?ad_id=3D1356&alloc_id=3D3438&op=3Dclick
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

Re: [Springframework-developer] DataFieldMaxValueIncrementer

[<jue...@we...>]

Actually, MySQLMaxValueIncrementer does leverage the value cache in a =
meaningful way, and HsqlMaxValueIncrementer at least just issues a =
single delete for the entire advance cache. But the sequence-based =
incrementers, i.e. OracleSequenceMaxValueIncrementer and the new =
PostgreSQLSequenceMaxValueIncrementer do not benefit from the value =
cache at all. So I just suggest to remove the value cache from the =
sequence-based incrementers.
=20
Juergen
=20

________________________________

Von: spr...@li... im Auftrag =
von j=FCrgen h=F6ller [werk3AT]
Gesendet: Do 26.02.2004 08:25
An: spr...@li...
Betreff: Re: [Springframework-developer] DataFieldMaxValueIncrementer



I'm done with the simplicication so far - less than half of the code =
remains ;-)

However, there's still the value cache. I strongly doubt that this is a =
good idea, particularly with database sequences. Essentially, if the =
cache size is 10, we're accessing the sequence 10 times in advance =
instead of asking in whenever an id is requested. There's the same =
amount of SQL statements involved; what's the benefit here?

The drawback is that we need to synchronize cache access for this. If we =
simply went straight to the database sequence for each id, we could =
delegate concurrency to the database. And I don't know of an O/R mapping =
tool that does such sequence value caching (please correct me if I'm =
wrong). All things considered, I suggest to drop the value cache =
completely.

Juergen


________________________________

Von: spr...@li... im Auftrag =
von tri...@tr...
Gesendet: Mi 25.02.2004 23:02
An: spr...@li...
Betreff: Re: [Springframework-developer] DataFieldMaxValueIncrementer




+1

I never understood the need for a double as an incrementer anyway.  =
Simple is
better.  The OracleSequenceMaxValueIncrementer could use some =
refactoring too.
We don't need a SqlFunction - we should be able to use the new =
queryForXxxx
methods on the JDBC Template.  Once you check in your changes, I can =
take a look
at the Oracle one.

Thomas

Quoting "j=FCrgen h=F6ller [werk3AT]" <jue...@we...>:

> I've added PostgreSQLSequenceMaxValueIncrementer today, as attached to =
=3D
> our JIRA. On the occasion, I've reviewed the incrementer =3D
> implementations: They're too complicated for what they achieve, =3D
> IMO.Thus, I've dropped the inner class NextMaxValueProviders and moved =
=3D
> the code to the DataFieldMaxValueIncrementer class hierarchy itself.
> =3D20
> I've noticed that AbstractDataFieldMaxValueIncrementer's =
nextDoubleValue =3D
> effectively returns an integer, like nextIntValue/nextLongValue - =
after =3D
> all, the template method getNextKey returns a long, so there's no =
chance =3D
> for a true double. Thus, I see no point in keeping the nextDoubleValue =
=3D
> method in the DataFieldMaxValueIncrementer interface; all current =3D
> implementations do not return doubles here.
> =3D20
> Furthermore, why does getNextKey take a type parameter when it returns =
a =3D
> long anyway? Any JDBC driver will let you read both an int and a long =
=3D
> via rs.getLong, so there's no point in that type parameter. Simply =3D
> reading the value via getLong should be sufficient.
> =3D20
> This leaves a very simple DataFieldMaxValueIncrementer interface with =
=3D
> nextIntValue, nextLongValue and nextStringValue methods, with =3D
> implementations that achieve their goal in a straightforward fashion. =
=3D
> AbstractDataFieldMaxValueIncrementer delegates all three to getNextKey =
=3D
> which returns a long, casting the long to an int respectively =
converting =3D
> it to a string with optional padding.
> =3D20
> This should still cover all current usages and therefore not break =3D
> compatibility, and it should make it as easy as possible to implement =
an =3D
> AbstractDataFieldMaxValueIncrementer subclass for a specific database. =
=3D
> Thomas, Dmitrity, what do you think?
> =3D20
> Juergen
> =3D20
> P.S.:
> Obviously, 1.0 RC2 won't be released tonight but rather at the end of =
=3D
> the week. I believe it's worth it, as I'd also like to wait for =
feedback =3D
> on the other recent changes.
> =3D20
>
>
> -------------------------------------------------------
> SF.Net is sponsored by: Speed Start Your Linux Apps Now.
> Build and deploy apps & Web services for Linux with
> a free DVD software kit from IBM. Click Now!
> http://ads.osdn.com/?ad_id=3D1356&alloc_id=3D3438&op=3Dclick
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>





-------------------------------------------------------
SF.Net is sponsored by: Speed Start Your Linux Apps Now.
Build and deploy apps & Web services for Linux with
a free DVD software kit from IBM. Click Now!
http://ads.osdn.com/?ad_id=3D1356&alloc_id=3D3438&op=3Dclick
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer




-------------------------------------------------------
SF.Net is sponsored by: Speed Start Your Linux Apps Now.
Build and deploy apps & Web services for Linux with
a free DVD software kit from IBM. Click Now!
http://ads.osdn.com/?ad_id=1356&alloc_id438&op=3Dick
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

RE: [Springframework-developer] DataFieldMaxValueIncrementer

[Dmitriy K. <dko...@ru...>]

+1 for removing cache from sequence-based incrementers

-----Original Message-----
From: spr...@li...
[mailto:spr...@li...] On Behalf =
Of
j=FCrgen h=F6ller [werk3AT]
Sent: Thursday, February 26, 2004 2:43 AM
To: spr...@li...;
spr...@li...
Subject: Re: [Springframework-developer] DataFieldMaxValueIncrementer


Actually, MySQLMaxValueIncrementer does leverage the value cache in a
meaningful way, and HsqlMaxValueIncrementer at least just issues a =
single
delete for the entire advance cache. But the sequence-based =
incrementers,
i.e. OracleSequenceMaxValueIncrementer and the new
PostgreSQLSequenceMaxValueIncrementer do not benefit from the value =
cache at
all. So I just suggest to remove the value cache from the sequence-based
incrementers.
=20
Juergen
=20

________________________________

Von: spr...@li... im Auftrag =
von
j=FCrgen h=F6ller [werk3AT]
Gesendet: Do 26.02.2004 08:25
An: spr...@li...
Betreff: Re: [Springframework-developer] DataFieldMaxValueIncrementer



I'm done with the simplicication so far - less than half of the code =
remains
;-)

However, there's still the value cache. I strongly doubt that this is a =
good
idea, particularly with database sequences. Essentially, if the cache =
size
is 10, we're accessing the sequence 10 times in advance instead of =
asking in
whenever an id is requested. There's the same amount of SQL statements
involved; what's the benefit here?

The drawback is that we need to synchronize cache access for this. If we
simply went straight to the database sequence for each id, we could =
delegate
concurrency to the database. And I don't know of an O/R mapping tool =
that
does such sequence value caching (please correct me if I'm wrong). All
things considered, I suggest to drop the value cache completely.

Juergen


________________________________

Von: spr...@li... im Auftrag =
von
tri...@tr...
Gesendet: Mi 25.02.2004 23:02
An: spr...@li...
Betreff: Re: [Springframework-developer] DataFieldMaxValueIncrementer




+1

I never understood the need for a double as an incrementer anyway.  =
Simple
is better.  The OracleSequenceMaxValueIncrementer could use some =
refactoring
too. We don't need a SqlFunction - we should be able to use the new
queryForXxxx methods on the JDBC Template.  Once you check in your =
changes,
I can take a look at the Oracle one.

Thomas

Quoting "j=FCrgen h=F6ller [werk3AT]" <jue...@we...>:

> I've added PostgreSQLSequenceMaxValueIncrementer today, as attached to =

> =3D our JIRA. On the occasion, I've reviewed the incrementer =3D
> implementations: They're too complicated for what they achieve, =3D=20
> IMO.Thus, I've dropped the inner class NextMaxValueProviders and moved =

> =3D the code to the DataFieldMaxValueIncrementer class hierarchy =
itself.=20
> =3D20 I've noticed that AbstractDataFieldMaxValueIncrementer's=20
> nextDoubleValue =3D effectively returns an integer, like=20
> nextIntValue/nextLongValue - after =3D all, the template method=20
> getNextKey returns a long, so there's no chance =3D for a true double. =

> Thus, I see no point in keeping the nextDoubleValue =3D method in the=20
> DataFieldMaxValueIncrementer interface; all current =3D =
implementations=20
> do not return doubles here. =3D20
> Furthermore, why does getNextKey take a type parameter when it returns =
a =3D
> long anyway? Any JDBC driver will let you read both an int and a long =
=3D
> via rs.getLong, so there's no point in that type parameter. Simply =3D
> reading the value via getLong should be sufficient.
> =3D20
> This leaves a very simple DataFieldMaxValueIncrementer interface with =
=3D
> nextIntValue, nextLongValue and nextStringValue methods, with =3D
> implementations that achieve their goal in a straightforward fashion. =
=3D
> AbstractDataFieldMaxValueIncrementer delegates all three to getNextKey =
=3D
> which returns a long, casting the long to an int respectively =
converting =3D
> it to a string with optional padding.
> =3D20
> This should still cover all current usages and therefore not break =3D
> compatibility, and it should make it as easy as possible to implement =
an =3D
> AbstractDataFieldMaxValueIncrementer subclass for a specific database. =
=3D
> Thomas, Dmitrity, what do you think?
> =3D20
> Juergen
> =3D20
> P.S.:
> Obviously, 1.0 RC2 won't be released tonight but rather at the end of =
=3D
> the week. I believe it's worth it, as I'd also like to wait for =
feedback =3D
> on the other recent changes.
> =3D20
>
>
> -------------------------------------------------------
> SF.Net is sponsored by: Speed Start Your Linux Apps Now. Build and=20
> deploy apps & Web services for Linux with a free DVD software kit from =

> IBM. Click Now! =
http://ads.osdn.com/?ad_id=3D1356&alloc_id=3D3438&op=3Dclick
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>





-------------------------------------------------------
SF.Net is sponsored by: Speed Start Your Linux Apps Now.
Build and deploy apps & Web services for Linux with
a free DVD software kit from IBM. Click Now!
http://ads.osdn.com/?ad_id=3D1356&alloc_id=3D3438&op=3Dclick
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer




-------------------------------------------------------
SF.Net is sponsored by: Speed Start Your Linux Apps Now.
Build and deploy apps & Web services for Linux with
a free DVD software kit from IBM. Click Now!
http://ads.osdn.com/?ad_id=1356&alloc_id438&op=3Dick
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer




-------------------------------------------------------
SF.Net is sponsored by: Speed Start Your Linux Apps Now.
Build and deploy apps & Web services for Linux with
a free DVD software kit from IBM. Click Now!
http://ads.osdn.com/?ad_id=1356&alloc_id438&op=3Dclick
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

Re: [Springframework-developer] DataFieldMaxValueIncrementer

[<jue...@we...>]

I've committed the revised DataFieldMaxValueIncrementer hierarchy. There =
is a new AbstractSequenceMaxValueIncrementer now, with no value cache =
anymore. OracleSequenceMaxValueIncrementer and =
PostgreSQLSequenceMaxValueIncrementer are very simple classes of this =
new base class. In general, there's significantly less code involved =
than before.
=20
I've decided to implement AbstractSequenceMaxValueIncrementer based on =
plain JDBC, to be able to throw proper sequence-related exceptions. A =
queryForLong wouldn't be a particularly useful extension of =
JdbcTemplate, and it would throw DataAccessApiUsageExceptions if no row =
found or the like - not appropriate when the user didn't specify the =
query in the first place.
=20
I've also written unit tests for all incrementers. I just did a live =
test of HsqlMaxValueIncrementer; gonna test MySQLMaxValueIncrementer =
later today. Dmitriy, Thomas, could you have a look at the revision, and =
test OracleSequenceMaxValueIncrementer (and possibly =
PostgreSQLSequenceMaxValueIncrementer).
=20
Juergen
=20

________________________________

Von: spr...@li... im Auftrag =
von Dmitriy Kopylenko
Gesendet: Do 26.02.2004 14:33
An: spr...@li...
Betreff: RE: [Springframework-developer] DataFieldMaxValueIncrementer



+1 for removing cache from sequence-based incrementers

-----Original Message-----
From: spr...@li...
[mailto:spr...@li...] On Behalf =
Of
j=FCrgen h=F6ller [werk3AT]
Sent: Thursday, February 26, 2004 2:43 AM
To: spr...@li...;
spr...@li...
Subject: Re: [Springframework-developer] DataFieldMaxValueIncrementer


Actually, MySQLMaxValueIncrementer does leverage the value cache in a
meaningful way, and HsqlMaxValueIncrementer at least just issues a =
single
delete for the entire advance cache. But the sequence-based =
incrementers,
i.e. OracleSequenceMaxValueIncrementer and the new
PostgreSQLSequenceMaxValueIncrementer do not benefit from the value =
cache at
all. So I just suggest to remove the value cache from the sequence-based
incrementers.

Juergen


________________________________

Von: spr...@li... im Auftrag =
von
j=FCrgen h=F6ller [werk3AT]
Gesendet: Do 26.02.2004 08:25
An: spr...@li...
Betreff: Re: [Springframework-developer] DataFieldMaxValueIncrementer



I'm done with the simplicication so far - less than half of the code =
remains
;-)

However, there's still the value cache. I strongly doubt that this is a =
good
idea, particularly with database sequences. Essentially, if the cache =
size
is 10, we're accessing the sequence 10 times in advance instead of =
asking in
whenever an id is requested. There's the same amount of SQL statements
involved; what's the benefit here?

The drawback is that we need to synchronize cache access for this. If we
simply went straight to the database sequence for each id, we could =
delegate
concurrency to the database. And I don't know of an O/R mapping tool =
that
does such sequence value caching (please correct me if I'm wrong). All
things considered, I suggest to drop the value cache completely.

Juergen


________________________________

Von: spr...@li... im Auftrag =
von
tri...@tr...
Gesendet: Mi 25.02.2004 23:02
An: spr...@li...
Betreff: Re: [Springframework-developer] DataFieldMaxValueIncrementer




+1

I never understood the need for a double as an incrementer anyway.  =
Simple
is better.  The OracleSequenceMaxValueIncrementer could use some =
refactoring
too. We don't need a SqlFunction - we should be able to use the new
queryForXxxx methods on the JDBC Template.  Once you check in your =
changes,
I can take a look at the Oracle one.

Thomas

Quoting "j=FCrgen h=F6ller [werk3AT]" <jue...@we...>:

> I've added PostgreSQLSequenceMaxValueIncrementer today, as attached to
> =3D our JIRA. On the occasion, I've reviewed the incrementer =3D
> implementations: They're too complicated for what they achieve, =3D
> IMO.Thus, I've dropped the inner class NextMaxValueProviders and moved
> =3D the code to the DataFieldMaxValueIncrementer class hierarchy =
itself.
> =3D20 I've noticed that AbstractDataFieldMaxValueIncrementer's
> nextDoubleValue =3D effectively returns an integer, like
> nextIntValue/nextLongValue - after =3D all, the template method
> getNextKey returns a long, so there's no chance =3D for a true double.
> Thus, I see no point in keeping the nextDoubleValue =3D method in the
> DataFieldMaxValueIncrementer interface; all current =3D =
implementations
> do not return doubles here. =3D20
> Furthermore, why does getNextKey take a type parameter when it returns =
a =3D
> long anyway? Any JDBC driver will let you read both an int and a long =
=3D
> via rs.getLong, so there's no point in that type parameter. Simply =3D
> reading the value via getLong should be sufficient.
> =3D20
> This leaves a very simple DataFieldMaxValueIncrementer interface with =
=3D
> nextIntValue, nextLongValue and nextStringValue methods, with =3D
> implementations that achieve their goal in a straightforward fashion. =
=3D
> AbstractDataFieldMaxValueIncrementer delegates all three to getNextKey =
=3D
> which returns a long, casting the long to an int respectively =
converting =3D
> it to a string with optional padding.
> =3D20
> This should still cover all current usages and therefore not break =3D
> compatibility, and it should make it as easy as possible to implement =
an =3D
> AbstractDataFieldMaxValueIncrementer subclass for a specific database. =
=3D
> Thomas, Dmitrity, what do you think?
> =3D20
> Juergen
> =3D20
> P.S.:
> Obviously, 1.0 RC2 won't be released tonight but rather at the end of =
=3D
> the week. I believe it's worth it, as I'd also like to wait for =
feedback =3D
> on the other recent changes.
> =3D20
>
>
> -------------------------------------------------------
> SF.Net is sponsored by: Speed Start Your Linux Apps Now. Build and
> deploy apps & Web services for Linux with a free DVD software kit from
> IBM. Click Now! =
http://ads.osdn.com/?ad_id=3D1356&alloc_id=3D3438&op=3Dclick
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>





-------------------------------------------------------
SF.Net is sponsored by: Speed Start Your Linux Apps Now.
Build and deploy apps & Web services for Linux with
a free DVD software kit from IBM. Click Now!
http://ads.osdn.com/?ad_id=3D1356&alloc_id=3D3438&op=3Dclick
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer




-------------------------------------------------------
SF.Net is sponsored by: Speed Start Your Linux Apps Now.
Build and deploy apps & Web services for Linux with
a free DVD software kit from IBM. Click Now!
http://ads.osdn.com/?ad_id=1356&alloc_id438&op=3Dick
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer




-------------------------------------------------------
SF.Net is sponsored by: Speed Start Your Linux Apps Now.
Build and deploy apps & Web services for Linux with
a free DVD software kit from IBM. Click Now!
http://ads.osdn.com/?ad_id=1356&alloc_id438&op=3Dclick
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer



-------------------------------------------------------
SF.Net is sponsored by: Speed Start Your Linux Apps Now.
Build and deploy apps & Web services for Linux with
a free DVD software kit from IBM. Click Now!
http://ads.osdn.com/?ad_id=1356&alloc_id438&op=3Dick
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

Re: [Springframework-developer] DataFieldMaxValueIncrementer

[<tri...@tr...>]

Juergen,

You broke all my existing tests :-)  The DriverManagerDataSource now throws a
ClassNotFoundException which is a checked exception.  It used to rethrow this as
an unchecked exception.  I can live with this change, but do we want to change
this behavior at this point?

As for the Incrementers - I'm going totest them today.

Thomas


Quoting "jürgen höller [werk3AT]" <jue...@we...>:

> I've committed the revised DataFieldMaxValueIncrementer hierarchy. There =
> is a new AbstractSequenceMaxValueIncrementer now, with no value cache =
> anymore. OracleSequenceMaxValueIncrementer and =
> PostgreSQLSequenceMaxValueIncrementer are very simple classes of this =
> new base class. In general, there's significantly less code involved =
> than before.
> =20
> I've decided to implement AbstractSequenceMaxValueIncrementer based on =
> plain JDBC, to be able to throw proper sequence-related exceptions. A =
> queryForLong wouldn't be a particularly useful extension of =
> JdbcTemplate, and it would throw DataAccessApiUsageExceptions if no row =
> found or the like - not appropriate when the user didn't specify the =
> query in the first place.
> =20
> I've also written unit tests for all incrementers. I just did a live =
> test of HsqlMaxValueIncrementer; gonna test MySQLMaxValueIncrementer =
> later today. Dmitriy, Thomas, could you have a look at the revision, and =
> test OracleSequenceMaxValueIncrementer (and possibly =
> PostgreSQLSequenceMaxValueIncrementer).
> =20
> Juergen
> =20
> 
> ________________________________
> 
> Von: spr...@li... im Auftrag =
> von Dmitriy Kopylenko
> Gesendet: Do 26.02.2004 14:33
> An: spr...@li...
> Betreff: RE: [Springframework-developer] DataFieldMaxValueIncrementer
> 
> 
> 
> +1 for removing cache from sequence-based incrementers
> 
> -----Original Message-----
> From: spr...@li...
> [mailto:spr...@li...] On Behalf =
> Of
> j=FCrgen h=F6ller [werk3AT]
> Sent: Thursday, February 26, 2004 2:43 AM
> To: spr...@li...;
> spr...@li...
> Subject: Re: [Springframework-developer] DataFieldMaxValueIncrementer
> 
> 
> Actually, MySQLMaxValueIncrementer does leverage the value cache in a
> meaningful way, and HsqlMaxValueIncrementer at least just issues a =
> single
> delete for the entire advance cache. But the sequence-based =
> incrementers,
> i.e. OracleSequenceMaxValueIncrementer and the new
> PostgreSQLSequenceMaxValueIncrementer do not benefit from the value =
> cache at
> all. So I just suggest to remove the value cache from the sequence-based
> incrementers.
> 
> Juergen
> 
> 
> ________________________________
> 
> Von: spr...@li... im Auftrag =
> von
> j=FCrgen h=F6ller [werk3AT]
> Gesendet: Do 26.02.2004 08:25
> An: spr...@li...
> Betreff: Re: [Springframework-developer] DataFieldMaxValueIncrementer
> 
> 
> 
> I'm done with the simplicication so far - less than half of the code =
> remains
> ;-)
> 
> However, there's still the value cache. I strongly doubt that this is a =
> good
> idea, particularly with database sequences. Essentially, if the cache =
> size
> is 10, we're accessing the sequence 10 times in advance instead of =
> asking in
> whenever an id is requested. There's the same amount of SQL statements
> involved; what's the benefit here?
> 
> The drawback is that we need to synchronize cache access for this. If we
> simply went straight to the database sequence for each id, we could =
> delegate
> concurrency to the database. And I don't know of an O/R mapping tool =
> that
> does such sequence value caching (please correct me if I'm wrong). All
> things considered, I suggest to drop the value cache completely.
> 
> Juergen
> 
> 
> ________________________________
> 
> Von: spr...@li... im Auftrag =
> von
> tri...@tr...
> Gesendet: Mi 25.02.2004 23:02
> An: spr...@li...
> Betreff: Re: [Springframework-developer] DataFieldMaxValueIncrementer
> 
> 
> 
> 
> +1
> 
> I never understood the need for a double as an incrementer anyway.  =
> Simple
> is better.  The OracleSequenceMaxValueIncrementer could use some =
> refactoring
> too. We don't need a SqlFunction - we should be able to use the new
> queryForXxxx methods on the JDBC Template.  Once you check in your =
> changes,
> I can take a look at the Oracle one.
> 
> Thomas
> 
> Quoting "j=FCrgen h=F6ller [werk3AT]" <jue...@we...>:
> 
> > I've added PostgreSQLSequenceMaxValueIncrementer today, as attached to
> > =3D our JIRA. On the occasion, I've reviewed the incrementer =3D
> > implementations: They're too complicated for what they achieve, =3D
> > IMO.Thus, I've dropped the inner class NextMaxValueProviders and moved
> > =3D the code to the DataFieldMaxValueIncrementer class hierarchy =
> itself.
> > =3D20 I've noticed that AbstractDataFieldMaxValueIncrementer's
> > nextDoubleValue =3D effectively returns an integer, like
> > nextIntValue/nextLongValue - after =3D all, the template method
> > getNextKey returns a long, so there's no chance =3D for a true double.
> > Thus, I see no point in keeping the nextDoubleValue =3D method in the
> > DataFieldMaxValueIncrementer interface; all current =3D =
> implementations
> > do not return doubles here. =3D20
> > Furthermore, why does getNextKey take a type parameter when it returns =
> a =3D
> > long anyway? Any JDBC driver will let you read both an int and a long =
> =3D
> > via rs.getLong, so there's no point in that type parameter. Simply =3D
> > reading the value via getLong should be sufficient.
> > =3D20
> > This leaves a very simple DataFieldMaxValueIncrementer interface with =
> =3D
> > nextIntValue, nextLongValue and nextStringValue methods, with =3D
> > implementations that achieve their goal in a straightforward fashion. =
> =3D
> > AbstractDataFieldMaxValueIncrementer delegates all three to getNextKey =
> =3D
> > which returns a long, casting the long to an int respectively =
> converting =3D
> > it to a string with optional padding.
> > =3D20
> > This should still cover all current usages and therefore not break =3D
> > compatibility, and it should make it as easy as possible to implement =
> an =3D
> > AbstractDataFieldMaxValueIncrementer subclass for a specific database. =
> =3D
> > Thomas, Dmitrity, what do you think?
> > =3D20
> > Juergen
> > =3D20
> > P.S.:
> > Obviously, 1.0 RC2 won't be released tonight but rather at the end of =
> =3D
> > the week. I believe it's worth it, as I'd also like to wait for =
> feedback =3D
> > on the other recent changes.
> > =3D20
> >
> >
> > -------------------------------------------------------
> > SF.Net is sponsored by: Speed Start Your Linux Apps Now. Build and
> > deploy apps & Web services for Linux with a free DVD software kit from
> > IBM. Click Now! =
> http://ads.osdn.com/?ad_id=3D1356&alloc_id=3D3438&op=3Dclick
> > _______________________________________________
> > Springframework-developer mailing list
> > Spr...@li...
> > https://lists.sourceforge.net/lists/listinfo/springframework-developer
> >
> 
> 
> 
> 
> 
> -------------------------------------------------------
> SF.Net is sponsored by: Speed Start Your Linux Apps Now.
> Build and deploy apps & Web services for Linux with
> a free DVD software kit from IBM. Click Now!
> http://ads.osdn.com/?ad_id=3D1356&alloc_id=3D3438&op=3Dclick
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
> 
> 
> 
> 
> -------------------------------------------------------
> SF.Net is sponsored by: Speed Start Your Linux Apps Now.
> Build and deploy apps & Web services for Linux with
> a free DVD software kit from IBM. Click Now!
> http://ads.osdn.com/?ad_id=1356&alloc_id438&op=3Dick
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
> 
> 
> 
> 
> -------------------------------------------------------
> SF.Net is sponsored by: Speed Start Your Linux Apps Now.
> Build and deploy apps & Web services for Linux with
> a free DVD software kit from IBM. Click Now!
> http://ads.osdn.com/?ad_id=1356&alloc_id438&op=3Dclick
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
> 
> 
> 
> -------------------------------------------------------
> SF.Net is sponsored by: Speed Start Your Linux Apps Now.
> Build and deploy apps & Web services for Linux with
> a free DVD software kit from IBM. Click Now!
> http://ads.osdn.com/?ad_id=1356&alloc_id438&op=3Dick
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
> 
> 
> 
> 
> -------------------------------------------------------
> SF.Net is sponsored by: Speed Start Your Linux Apps Now.
> Build and deploy apps & Web services for Linux with
> a free DVD software kit from IBM. Click Now!
> http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
> 

Re: [Springframework-developer] DataFieldMaxValueIncrementer

[<jue...@we...>]

Good point - changed to IllegalArgumentException. I just didn't want to =
throw CannotGetJdbcConnectionException like before; it arguably wasn't =
appropriate. In general. the DataSource implementations shouldn't use =
DataAccessExceptions in the first place.
=20
Juergen
=20

________________________________

Von: spr...@li... im Auftrag =
von tri...@tr...
Gesendet: Sa 28.02.2004 14:06
An: spr...@li...
Betreff: Re: [Springframework-developer] DataFieldMaxValueIncrementer




Juergen,

You broke all my existing tests :-)  The DriverManagerDataSource now =
throws a
ClassNotFoundException which is a checked exception.  It used to rethrow =
this as
an unchecked exception.  I can live with this change, but do we want to =
change
this behavior at this point?

As for the Incrementers - I'm going totest them today.

Thomas


Quoting "j=FCrgen h=F6ller [werk3AT]" <jue...@we...>:

> I've committed the revised DataFieldMaxValueIncrementer hierarchy. =
There =3D
> is a new AbstractSequenceMaxValueIncrementer now, with no value cache =
=3D
> anymore. OracleSequenceMaxValueIncrementer and =3D
> PostgreSQLSequenceMaxValueIncrementer are very simple classes of this =
=3D
> new base class. In general, there's significantly less code involved =
=3D
> than before.
> =3D20
> I've decided to implement AbstractSequenceMaxValueIncrementer based on =
=3D
> plain JDBC, to be able to throw proper sequence-related exceptions. A =
=3D
> queryForLong wouldn't be a particularly useful extension of =3D
> JdbcTemplate, and it would throw DataAccessApiUsageExceptions if no =
row =3D
> found or the like - not appropriate when the user didn't specify the =
=3D
> query in the first place.
> =3D20
> I've also written unit tests for all incrementers. I just did a live =
=3D
> test of HsqlMaxValueIncrementer; gonna test MySQLMaxValueIncrementer =
=3D
> later today. Dmitriy, Thomas, could you have a look at the revision, =
and =3D
> test OracleSequenceMaxValueIncrementer (and possibly =3D
> PostgreSQLSequenceMaxValueIncrementer).
> =3D20
> Juergen
> =3D20
>
> ________________________________
>
> Von: spr...@li... im Auftrag =
=3D
> von Dmitriy Kopylenko
> Gesendet: Do 26.02.2004 14:33
> An: spr...@li...
> Betreff: RE: [Springframework-developer] DataFieldMaxValueIncrementer
>
>
>
> +1 for removing cache from sequence-based incrementers
>
> -----Original Message-----
> From: spr...@li...
> [mailto:spr...@li...] On =
Behalf =3D
> Of
> j=3DFCrgen h=3DF6ller [werk3AT]
> Sent: Thursday, February 26, 2004 2:43 AM
> To: spr...@li...;
> spr...@li...
> Subject: Re: [Springframework-developer] DataFieldMaxValueIncrementer
>
>
> Actually, MySQLMaxValueIncrementer does leverage the value cache in a
> meaningful way, and HsqlMaxValueIncrementer at least just issues a =3D
> single
> delete for the entire advance cache. But the sequence-based =3D
> incrementers,
> i.e. OracleSequenceMaxValueIncrementer and the new
> PostgreSQLSequenceMaxValueIncrementer do not benefit from the value =
=3D
> cache at
> all. So I just suggest to remove the value cache from the =
sequence-based
> incrementers.
>
> Juergen
>
>
> ________________________________
>
> Von: spr...@li... im Auftrag =
=3D
> von
> j=3DFCrgen h=3DF6ller [werk3AT]
> Gesendet: Do 26.02.2004 08:25
> An: spr...@li...
> Betreff: Re: [Springframework-developer] DataFieldMaxValueIncrementer
>
>
>
> I'm done with the simplicication so far - less than half of the code =
=3D
> remains
> ;-)
>
> However, there's still the value cache. I strongly doubt that this is =
a =3D
> good
> idea, particularly with database sequences. Essentially, if the cache =
=3D
> size
> is 10, we're accessing the sequence 10 times in advance instead of =3D
> asking in
> whenever an id is requested. There's the same amount of SQL statements
> involved; what's the benefit here?
>
> The drawback is that we need to synchronize cache access for this. If =
we
> simply went straight to the database sequence for each id, we could =
=3D
> delegate
> concurrency to the database. And I don't know of an O/R mapping tool =
=3D
> that
> does such sequence value caching (please correct me if I'm wrong). All
> things considered, I suggest to drop the value cache completely.
>
> Juergen
>
>
> ________________________________
>
> Von: spr...@li... im Auftrag =
=3D
> von
> tri...@tr...
> Gesendet: Mi 25.02.2004 23:02
> An: spr...@li...
> Betreff: Re: [Springframework-developer] DataFieldMaxValueIncrementer
>
>
>
>
> +1
>
> I never understood the need for a double as an incrementer anyway.  =
=3D
> Simple
> is better.  The OracleSequenceMaxValueIncrementer could use some =3D
> refactoring
> too. We don't need a SqlFunction - we should be able to use the new
> queryForXxxx methods on the JDBC Template.  Once you check in your =3D
> changes,
> I can take a look at the Oracle one.
>
> Thomas
>
> Quoting "j=3DFCrgen h=3DF6ller [werk3AT]" =
<jue...@we...>:
>
> > I've added PostgreSQLSequenceMaxValueIncrementer today, as attached =
to
> > =3D3D our JIRA. On the occasion, I've reviewed the incrementer =3D3D
> > implementations: They're too complicated for what they achieve, =
=3D3D
> > IMO.Thus, I've dropped the inner class NextMaxValueProviders and =
moved
> > =3D3D the code to the DataFieldMaxValueIncrementer class hierarchy =
=3D
> itself.
> > =3D3D20 I've noticed that AbstractDataFieldMaxValueIncrementer's
> > nextDoubleValue =3D3D effectively returns an integer, like
> > nextIntValue/nextLongValue - after =3D3D all, the template method
> > getNextKey returns a long, so there's no chance =3D3D for a true =
double.
> > Thus, I see no point in keeping the nextDoubleValue =3D3D method in =
the
> > DataFieldMaxValueIncrementer interface; all current =3D3D =3D
> implementations
> > do not return doubles here. =3D3D20
> > Furthermore, why does getNextKey take a type parameter when it =
returns =3D
> a =3D3D
> > long anyway? Any JDBC driver will let you read both an int and a =
long =3D
> =3D3D
> > via rs.getLong, so there's no point in that type parameter. Simply =
=3D3D
> > reading the value via getLong should be sufficient.
> > =3D3D20
> > This leaves a very simple DataFieldMaxValueIncrementer interface =
with =3D
> =3D3D
> > nextIntValue, nextLongValue and nextStringValue methods, with =3D3D
> > implementations that achieve their goal in a straightforward =
fashion. =3D
> =3D3D
> > AbstractDataFieldMaxValueIncrementer delegates all three to =
getNextKey =3D
> =3D3D
> > which returns a long, casting the long to an int respectively =3D
> converting =3D3D
> > it to a string with optional padding.
> > =3D3D20
> > This should still cover all current usages and therefore not break =
=3D3D
> > compatibility, and it should make it as easy as possible to =
implement =3D
> an =3D3D
> > AbstractDataFieldMaxValueIncrementer subclass for a specific =
database. =3D
> =3D3D
> > Thomas, Dmitrity, what do you think?
> > =3D3D20
> > Juergen
> > =3D3D20
> > P.S.:
> > Obviously, 1.0 RC2 won't be released tonight but rather at the end =
of =3D
> =3D3D
> > the week. I believe it's worth it, as I'd also like to wait for =3D
> feedback =3D3D
> > on the other recent changes.
> > =3D3D20
> >
> >
> > -------------------------------------------------------
> > SF.Net is sponsored by: Speed Start Your Linux Apps Now. Build and
> > deploy apps & Web services for Linux with a free DVD software kit =
from
> > IBM. Click Now! =3D
> http://ads.osdn.com/?ad_id=3D3D1356&alloc_id=3D3D3438&op=3D3Dclick
> > _______________________________________________
> > Springframework-developer mailing list
> > Spr...@li...
> > =
https://lists.sourceforge.net/lists/listinfo/springframework-developer
> >
>
>
>
>
>
> -------------------------------------------------------
> SF.Net is sponsored by: Speed Start Your Linux Apps Now.
> Build and deploy apps & Web services for Linux with
> a free DVD software kit from IBM. Click Now!
> http://ads.osdn.com/?ad_id=3D3D1356&alloc_id=3D3D3438&op=3D3Dclick
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>
>
>
>
> -------------------------------------------------------
> SF.Net is sponsored by: Speed Start Your Linux Apps Now.
> Build and deploy apps & Web services for Linux with
> a free DVD software kit from IBM. Click Now!
> http://ads.osdn.com/?ad_id=3D1356&alloc_id438&op=3D3Dick
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>
>
>
>
> -------------------------------------------------------
> SF.Net is sponsored by: Speed Start Your Linux Apps Now.
> Build and deploy apps & Web services for Linux with
> a free DVD software kit from IBM. Click Now!
> http://ads.osdn.com/?ad_id=3D1356&alloc_id438&op=3D3Dclick
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>
>
>
> -------------------------------------------------------
> SF.Net is sponsored by: Speed Start Your Linux Apps Now.
> Build and deploy apps & Web services for Linux with
> a free DVD software kit from IBM. Click Now!
> http://ads.osdn.com/?ad_id=3D1356&alloc_id438&op=3D3Dick
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>
>
>
>
> -------------------------------------------------------
> SF.Net is sponsored by: Speed Start Your Linux Apps Now.
> Build and deploy apps & Web services for Linux with
> a free DVD software kit from IBM. Click Now!
> http://ads.osdn.com/?ad_id=3D1356&alloc_id=3D3438&op=3Dclick
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>





-------------------------------------------------------
SF.Net is sponsored by: Speed Start Your Linux Apps Now.
Build and deploy apps & Web services for Linux with
a free DVD software kit from IBM. Click Now!
http://ads.osdn.com/?ad_id=3D1356&alloc_id=3D3438&op=3Dclick
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

Re: [Springframework-developer] DataFieldMaxValueIncrementer

[<tri...@tr...>]

I tested the Oracle and PostgreSQL incrementers - they work fine now.  I took
out the instance variable "sequenceQuery" since it was only set during
afterPropertiesSet - not always called if I create this programatically.  I
changed it to use getSequenceQuery() directly in the executeQuery() statement
instead.

I also fixed the SPR-50 issue regarding setNull for a named Array type.  For 1.1
we should add support for more complex types like REF and JAVA_OBJECT along with
ARRAY - I have not tested and I'm not sure we support all the different oddball
types for Oracle in particular.

Thomas


Quoting "jürgen höller [werk3AT]" <jue...@we...>:

> Good point - changed to IllegalArgumentException. I just didn't want to =
> throw CannotGetJdbcConnectionException like before; it arguably wasn't =
> appropriate. In general. the DataSource implementations shouldn't use =
> DataAccessExceptions in the first place.
> =20
> Juergen
> =20
> 
> ________________________________
> 
> Von: spr...@li... im Auftrag =
> von tri...@tr...
> Gesendet: Sa 28.02.2004 14:06
> An: spr...@li...
> Betreff: Re: [Springframework-developer] DataFieldMaxValueIncrementer
> 
> 
> 
> 
> Juergen,
> 
> You broke all my existing tests :-)  The DriverManagerDataSource now =
> throws a
> ClassNotFoundException which is a checked exception.  It used to rethrow =
> this as
> an unchecked exception.  I can live with this change, but do we want to =
> change
> this behavior at this point?
> 
> As for the Incrementers - I'm going totest them today.
> 
> Thomas
> 
> 
> Quoting "j=FCrgen h=F6ller [werk3AT]" <jue...@we...>:
> 
> > I've committed the revised DataFieldMaxValueIncrementer hierarchy. =
> There =3D
> > is a new AbstractSequenceMaxValueIncrementer now, with no value cache =
> =3D
> > anymore. OracleSequenceMaxValueIncrementer and =3D
> > PostgreSQLSequenceMaxValueIncrementer are very simple classes of this =
> =3D
> > new base class. In general, there's significantly less code involved =
> =3D
> > than before.
> > =3D20
> > I've decided to implement AbstractSequenceMaxValueIncrementer based on =
> =3D
> > plain JDBC, to be able to throw proper sequence-related exceptions. A =
> =3D
> > queryForLong wouldn't be a particularly useful extension of =3D
> > JdbcTemplate, and it would throw DataAccessApiUsageExceptions if no =
> row =3D
> > found or the like - not appropriate when the user didn't specify the =
> =3D
> > query in the first place.
> > =3D20
> > I've also written unit tests for all incrementers. I just did a live =
> =3D
> > test of HsqlMaxValueIncrementer; gonna test MySQLMaxValueIncrementer =
> =3D
> > later today. Dmitriy, Thomas, could you have a look at the revision, =
> and =3D
> > test OracleSequenceMaxValueIncrementer (and possibly =3D
> > PostgreSQLSequenceMaxValueIncrementer).
> > =3D20
> > Juergen
> > =3D20
> >
> > ________________________________
> >
> > Von: spr...@li... im Auftrag =
> =3D
> > von Dmitriy Kopylenko
> > Gesendet: Do 26.02.2004 14:33
> > An: spr...@li...
> > Betreff: RE: [Springframework-developer] DataFieldMaxValueIncrementer
> >
> >
> >
> > +1 for removing cache from sequence-based incrementers
> >
> > -----Original Message-----
> > From: spr...@li...
> > [mailto:spr...@li...] On =
> Behalf =3D
> > Of
> > j=3DFCrgen h=3DF6ller [werk3AT]
> > Sent: Thursday, February 26, 2004 2:43 AM
> > To: spr...@li...;
> > spr...@li...
> > Subject: Re: [Springframework-developer] DataFieldMaxValueIncrementer
> >
> >
> > Actually, MySQLMaxValueIncrementer does leverage the value cache in a
> > meaningful way, and HsqlMaxValueIncrementer at least just issues a =3D
> > single
> > delete for the entire advance cache. But the sequence-based =3D
> > incrementers,
> > i.e. OracleSequenceMaxValueIncrementer and the new
> > PostgreSQLSequenceMaxValueIncrementer do not benefit from the value =
> =3D
> > cache at
> > all. So I just suggest to remove the value cache from the =
> sequence-based
> > incrementers.
> >
> > Juergen
> >
> >
> > ________________________________
> >
> > Von: spr...@li... im Auftrag =
> =3D
> > von
> > j=3DFCrgen h=3DF6ller [werk3AT]
> > Gesendet: Do 26.02.2004 08:25
> > An: spr...@li...
> > Betreff: Re: [Springframework-developer] DataFieldMaxValueIncrementer
> >
> >
> >
> > I'm done with the simplicication so far - less than half of the code =
> =3D
> > remains
> > ;-)
> >
> > However, there's still the value cache. I strongly doubt that this is =
> a =3D
> > good
> > idea, particularly with database sequences. Essentially, if the cache =
> =3D
> > size
> > is 10, we're accessing the sequence 10 times in advance instead of =3D
> > asking in
> > whenever an id is requested. There's the same amount of SQL statements
> > involved; what's the benefit here?
> >
> > The drawback is that we need to synchronize cache access for this. If =
> we
> > simply went straight to the database sequence for each id, we could =
> =3D
> > delegate
> > concurrency to the database. And I don't know of an O/R mapping tool =
> =3D
> > that
> > does such sequence value caching (please correct me if I'm wrong). All
> > things considered, I suggest to drop the value cache completely.
> >
> > Juergen
> >
> >
> > ________________________________
> >
> > Von: spr...@li... im Auftrag =
> =3D
> > von
> > tri...@tr...
> > Gesendet: Mi 25.02.2004 23:02
> > An: spr...@li...
> > Betreff: Re: [Springframework-developer] DataFieldMaxValueIncrementer
> >
> >
> >
> >
> > +1
> >
> > I never understood the need for a double as an incrementer anyway.  =
> =3D
> > Simple
> > is better.  The OracleSequenceMaxValueIncrementer could use some =3D
> > refactoring
> > too. We don't need a SqlFunction - we should be able to use the new
> > queryForXxxx methods on the JDBC Template.  Once you check in your =3D
> > changes,
> > I can take a look at the Oracle one.
> >
> > Thomas
> >
> > Quoting "j=3DFCrgen h=3DF6ller [werk3AT]" =
> <jue...@we...>:
> >
> > > I've added PostgreSQLSequenceMaxValueIncrementer today, as attached =
> to
> > > =3D3D our JIRA. On the occasion, I've reviewed the incrementer =3D3D
> > > implementations: They're too complicated for what they achieve, =
> =3D3D
> > > IMO.Thus, I've dropped the inner class NextMaxValueProviders and =
> moved
> > > =3D3D the code to the DataFieldMaxValueIncrementer class hierarchy =
> =3D
> > itself.
> > > =3D3D20 I've noticed that AbstractDataFieldMaxValueIncrementer's
> > > nextDoubleValue =3D3D effectively returns an integer, like
> > > nextIntValue/nextLongValue - after =3D3D all, the template method
> > > getNextKey returns a long, so there's no chance =3D3D for a true =
> double.
> > > Thus, I see no point in keeping the nextDoubleValue =3D3D method in =
> the
> > > DataFieldMaxValueIncrementer interface; all current =3D3D =3D
> > implementations
> > > do not return doubles here. =3D3D20
> > > Furthermore, why does getNextKey take a type parameter when it =
> returns =3D
> > a =3D3D
> > > long anyway? Any JDBC driver will let you read both an int and a =
> long =3D
> > =3D3D
> > > via rs.getLong, so there's no point in that type parameter. Simply =
> =3D3D
> > > reading the value via getLong should be sufficient.
> > > =3D3D20
> > > This leaves a very simple DataFieldMaxValueIncrementer interface =
> with =3D
> > =3D3D
> > > nextIntValue, nextLongValue and nextStringValue methods, with =3D3D
> > > implementations that achieve their goal in a straightforward =
> fashion. =3D
> > =3D3D
> > > AbstractDataFieldMaxValueIncrementer delegates all three to =
> getNextKey =3D
> > =3D3D
> > > which returns a long, casting the long to an int respectively =3D
> > converting =3D3D
> > > it to a string with optional padding.
> > > =3D3D20
> > > This should still cover all current usages and therefore not break =
> =3D3D
> > > compatibility, and it should make it as easy as possible to =
> implement =3D
> > an =3D3D
> > > AbstractDataFieldMaxValueIncrementer subclass for a specific =
> database. =3D
> > =3D3D
> > > Thomas, Dmitrity, what do you think?
> > > =3D3D20
> > > Juergen
> > > =3D3D20
> > > P.S.:
> > > Obviously, 1.0 RC2 won't be released tonight but rather at the end =
> of =3D
> > =3D3D
> > > the week. I believe it's worth it, as I'd also like to wait for =3D
> > feedback =3D3D
> > > on the other recent changes.
> > > =3D3D20
> > >
> > >
> > > -------------------------------------------------------
> > > SF.Net is sponsored by: Speed Start Your Linux Apps Now. Build and
> > > deploy apps & Web services for Linux with a free DVD software kit =
> from
> > > IBM. Click Now! =3D
> > http://ads.osdn.com/?ad_id=3D3D1356&alloc_id=3D3D3438&op=3D3Dclick
> > > _______________________________________________
> > > Springframework-developer mailing list
> > > Spr...@li...
> > > =
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
> > >
> >
> >
> >
> >
> >
> > -------------------------------------------------------
> > SF.Net is sponsored by: Speed Start Your Linux Apps Now.
> > Build and deploy apps & Web services for Linux with
> > a free DVD software kit from IBM. Click Now!
> > http://ads.osdn.com/?ad_id=3D3D1356&alloc_id=3D3D3438&op=3D3Dclick
> > _______________________________________________
> > Springframework-developer mailing list
> > Spr...@li...
> > https://lists.sourceforge.net/lists/listinfo/springframework-developer
> >
> >
> >
> >
> > -------------------------------------------------------
> > SF.Net is sponsored by: Speed Start Your Linux Apps Now.
> > Build and deploy apps & Web services for Linux with
> > a free DVD software kit from IBM. Click Now!
> > http://ads.osdn.com/?ad_id=3D1356&alloc_id438&op=3D3Dick
> > _______________________________________________
> > Springframework-developer mailing list
> > Spr...@li...
> > https://lists.sourceforge.net/lists/listinfo/springframework-developer
> >
> >
> >
> >
> > -------------------------------------------------------
> > SF.Net is sponsored by: Speed Start Your Linux Apps Now.
> > Build and deploy apps & Web services for Linux with
> > a free DVD software kit from IBM. Click Now!
> > http://ads.osdn.com/?ad_id=3D1356&alloc_id438&op=3D3Dclick
> > _______________________________________________
> > Springframework-developer mailing list
> > Spr...@li...
> > https://lists.sourceforge.net/lists/listinfo/springframework-developer
> >
> >
> >
> > -------------------------------------------------------
> > SF.Net is sponsored by: Speed Start Your Linux Apps Now.
> > Build and deploy apps & Web services for Linux with
> > a free DVD software kit from IBM. Click Now!
> > http://ads.osdn.com/?ad_id=3D1356&alloc_id438&op=3D3Dick
> > _______________________________________________
> > Springframework-developer mailing list
> > Spr...@li...
> > https://lists.sourceforge.net/lists/listinfo/springframework-developer
> >
> >
> >
> >
> > -------------------------------------------------------
> > SF.Net is sponsored by: Speed Start Your Linux Apps Now.
> > Build and deploy apps & Web services for Linux with
> > a free DVD software kit from IBM. Click Now!
> > http://ads.osdn.com/?ad_id=3D1356&alloc_id=3D3438&op=3Dclick
> > _______________________________________________
> > Springframework-developer mailing list
> > Spr...@li...
> > https://lists.sourceforge.net/lists/listinfo/springframework-developer
> >
> 
> 
> 
> 
> 
> -------------------------------------------------------
> SF.Net is sponsored by: Speed Start Your Linux Apps Now.
> Build and deploy apps & Web services for Linux with
> a free DVD software kit from IBM. Click Now!
> http://ads.osdn.com/?ad_id=3D1356&alloc_id=3D3438&op=3Dclick
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
> 
> 
> 
> 
> -------------------------------------------------------
> SF.Net is sponsored by: Speed Start Your Linux Apps Now.
> Build and deploy apps & Web services for Linux with
> a free DVD software kit from IBM. Click Now!
> http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
> 

Re: [Springframework-developer] DataFieldMaxValueIncrementer

[Rod J. <rod...@in...>]

>Good point - changed to IllegalArgumentException.

>I just didn't want to throw CannotGetJdbcConnectionException like before;
it arguably wasn't appropriate. In general. the DataSource implementations
shouldn't use DataAccessExceptions in the first place.

I disagree. I think that the user should be able to catch
DataAccessException confidently in all cases (which was why I changed from
ClassNotFoundException to a DataAccessException).

I don't have terribly strong views on this as it's not a production usage
class anyway--but that also implies it wasn't really worth changing the
behaviour either...

Re: [Springframework-developer] DataFieldMaxValueIncrementer

[<tri...@tr...>]

How about a new JdbcResourceException extending
DataAccessResourceFailureException.   Btw could we rename the latter to
DataAccessResourceException - FailureException sounds like a double negative :-)

Thomas


Quoting Rod Johnson <rod...@in...>:

> 
> 
> 
> >Good point - changed to IllegalArgumentException.
> 
> >I just didn't want to throw CannotGetJdbcConnectionException like before;
> it arguably wasn't appropriate. In general. the DataSource implementations
> shouldn't use DataAccessExceptions in the first place.
> 
> I disagree. I think that the user should be able to catch
> DataAccessException confidently in all cases (which was why I changed from
> ClassNotFoundException to a DataAccessException).
> 
> I don't have terribly strong views on this as it's not a production usage
> class anyway--but that also implies it wasn't really worth changing the
> behaviour either...
> 
> 
> 
> 
> -------------------------------------------------------
> SF.Net is sponsored by: Speed Start Your Linux Apps Now.
> Build and deploy apps & Web services for Linux with
> a free DVD software kit from IBM. Click Now!
> http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
> 

Re: [Springframework-developer] DataFieldMaxValueIncrementer

[<jue...@we...>]

But the javax.sql.DataSource interface is plain JDBC, typically to be =
used by Spring DAOs just like any other DataSource. It's getConnection =
methods throw SQLException, according to the DataSource interface.
=20
This is about *setting up* a DriverManagerDataSource; I don't see why =
setDriverClassName or the constructor should throw a DataAccessException =
here. Other Spring beans - including DAO support classes - throw =
IllegalArgumentException or the like too when they get bad configuration =
parameters on initialization.
=20
As I said, I changed DriverManagerDataSource initialization to throw =
IllegalArgumentException, after Thomas' remark. The kind of unchecked =
exception thrown on initialization is a rather academic issue... In =
particular, if the driver class name isn't right, you can't do anything =
meaningful anyway.
=20
Juergen
=20

________________________________

Von: spr...@li... im Auftrag =
von Rod Johnson
Gesendet: Sa 28.02.2004 22:33
An: spr...@li...
Betreff: Re: [Springframework-developer] DataFieldMaxValueIncrementer






>Good point - changed to IllegalArgumentException.

>I just didn't want to throw CannotGetJdbcConnectionException like =
before;
it arguably wasn't appropriate. In general. the DataSource =
implementations
shouldn't use DataAccessExceptions in the first place.

I disagree. I think that the user should be able to catch
DataAccessException confidently in all cases (which was why I changed =
from
ClassNotFoundException to a DataAccessException).

I don't have terribly strong views on this as it's not a production =
usage
class anyway--but that also implies it wasn't really worth changing the
behaviour either...




-------------------------------------------------------
SF.Net is sponsored by: Speed Start Your Linux Apps Now.
Build and deploy apps & Web services for Linux with
a free DVD software kit from IBM. Click Now!
http://ads.osdn.com/?ad_id=3D1356&alloc_id=3D3438&op=3Dclick
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

Re: [Springframework-developer] DataFieldMaxValueIncrementer

[<tri...@tr...>]

It's not necessarily a bad argument though - it could just be that the runtime
environment is misconfigured - I think a JdbcResourceException (see previous
email) would be appropriate.

Thomas

Quoting "jürgen höller [werk3AT]" <jue...@we...>:

> But the javax.sql.DataSource interface is plain JDBC, typically to be =
> used by Spring DAOs just like any other DataSource. It's getConnection =
> methods throw SQLException, according to the DataSource interface.
> =20
> This is about *setting up* a DriverManagerDataSource; I don't see why =
> setDriverClassName or the constructor should throw a DataAccessException =
> here. Other Spring beans - including DAO support classes - throw =
> IllegalArgumentException or the like too when they get bad configuration =
> parameters on initialization.
> =20
> As I said, I changed DriverManagerDataSource initialization to throw =
> IllegalArgumentException, after Thomas' remark. The kind of unchecked =
> exception thrown on initialization is a rather academic issue... In =
> particular, if the driver class name isn't right, you can't do anything =
> meaningful anyway.
> =20
> Juergen
> =20
> 
> ________________________________
> 
> Von: spr...@li... im Auftrag =
> von Rod Johnson
> Gesendet: Sa 28.02.2004 22:33
> An: spr...@li...
> Betreff: Re: [Springframework-developer] DataFieldMaxValueIncrementer
> 
> 
> 
> 
> 
> 
> >Good point - changed to IllegalArgumentException.
> 
> >I just didn't want to throw CannotGetJdbcConnectionException like =
> before;
> it arguably wasn't appropriate. In general. the DataSource =
> implementations
> shouldn't use DataAccessExceptions in the first place.
> 
> I disagree. I think that the user should be able to catch
> DataAccessException confidently in all cases (which was why I changed =
> from
> ClassNotFoundException to a DataAccessException).
> 
> I don't have terribly strong views on this as it's not a production =
> usage
> class anyway--but that also implies it wasn't really worth changing the
> behaviour either...
> 
> 
> 
> 
> -------------------------------------------------------
> SF.Net is sponsored by: Speed Start Your Linux Apps Now.
> Build and deploy apps & Web services for Linux with
> a free DVD software kit from IBM. Click Now!
> http://ads.osdn.com/?ad_id=3D1356&alloc_id=3D3438&op=3Dclick
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
> 
> 
> 
> 
> -------------------------------------------------------
> SF.Net is sponsored by: Speed Start Your Linux Apps Now.
> Build and deploy apps & Web services for Linux with
> a free DVD software kit from IBM. Click Now!
> http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
> 

Re: [Springframework-developer] DataFieldMaxValueIncrementer

[Dmitriy K. <dko...@ru...>]

+1 for JdbcResourceException to be consistent with Spring Exception hiera=
rchy=2E=2E=2E

Regards=2C
Dmitriy=2E

----- Original Message -----
From=3A trisberg=40tridb=2Ecom
Date=3A Saturday=2C February 28=2C 2004 5=3A08 pm
Subject=3A Re=3A =5BSpringframework-developer=5D DataFieldMaxValueIncreme=
nter

=3E =

=3E It=27s not necessarily a bad argument though - it could just be that =

=3E the runtime
=3E environment is misconfigured - I think a JdbcResourceException =

=3E (see previous
=3E email) would be appropriate=2E
=3E =

=3E Thomas
=3E =

=3E Quoting =22j=C3=BCrgen h=C3=B6ller =5Bwerk3AT=5D=22 =3Cjuergen=2Ehoel=
ler=40werk3at=2Ecom=3E=3A
=3E =

=3E =3E But the javax=2Esql=2EDataSource interface is plain JDBC=2C typic=
ally =

=3E to be =3D
=3E =3E used by Spring DAOs just like any other DataSource=2E It=27s =

=3E getConnection =3D
=3E =3E methods throw SQLException=2C according to the DataSource interfa=
ce=2E
=3E =3E =3D20
=3E =3E This is about *setting up* a DriverManagerDataSource=3B I don=27t=
 =

=3E see why =3D
=3E =3E setDriverClassName or the constructor should throw a =

=3E DataAccessException =3D
=3E =3E here=2E Other Spring beans - including DAO support classes - thro=
w =3D
=3E =3E IllegalArgumentException or the like too when they get bad =

=3E configuration =3D
=3E =3E parameters on initialization=2E
=3E =3E =3D20
=3E =3E As I said=2C I changed DriverManagerDataSource initialization to =

=3E throw =3D
=3E =3E IllegalArgumentException=2C after Thomas=27 remark=2E The kind of=
 =

=3E unchecked =3D
=3E =3E exception thrown on initialization is a rather academic issue=2E=2E=
=2E =

=3E In =3D
=3E =3E particular=2C if the driver class name isn=27t right=2C you can=27=
t do =

=3E anything =3D
=3E =3E meaningful anyway=2E
=3E =3E =3D20
=3E =3E Juergen
=3E =3E =3D20
=3E =3E =

=3E =3E =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=
=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F
=3E =3E =

=3E =3E Von=3A springframework-developer-admin=40lists=2Esourceforge=2Ene=
t im =

=3E Auftrag =3D
=3E =3E von Rod Johnson
=3E =3E Gesendet=3A Sa 28=2E02=2E2004 22=3A33
=3E =3E An=3A springframework-developer=40lists=2Esourceforge=2Enet
=3E =3E Betreff=3A Re=3A =5BSpringframework-developer=5D =

=3E DataFieldMaxValueIncrementer=3E =

=3E =3E =

=3E =3E =

=3E =3E =

=3E =3E =

=3E =3E =

=3E =3E =3EGood point - changed to IllegalArgumentException=2E
=3E =3E =

=3E =3E =3EI just didn=27t want to throw CannotGetJdbcConnectionException=
 =

=3E like =3D
=3E =3E before=3B
=3E =3E it arguably wasn=27t appropriate=2E In general=2E the DataSource =
=3D
=3E =3E implementations
=3E =3E shouldn=27t use DataAccessExceptions in the first place=2E
=3E =3E =

=3E =3E I disagree=2E I think that the user should be able to catch
=3E =3E DataAccessException confidently in all cases (which was why I =

=3E changed =3D
=3E =3E from
=3E =3E ClassNotFoundException to a DataAccessException)=2E
=3E =3E =

=3E =3E I don=27t have terribly strong views on this as it=27s not a =

=3E production =3D
=3E =3E usage
=3E =3E class anyway--but that also implies it wasn=27t really worth =

=3E changing the
=3E =3E behaviour either=2E=2E=2E
=3E =3E =

=3E =3E =

=3E =3E =

=3E =3E =

=3E =3E -------------------------------------------------------
=3E =3E SF=2ENet is sponsored by=3A Speed Start Your Linux Apps Now=2E
=3E =3E Build and deploy apps =26 Web services for Linux with
=3E =3E a free DVD software kit from IBM=2E Click Now!
=3E =3E http=3A//ads=2Eosdn=2Ecom/=3Fad=5Fid=3D3D1356=26alloc=5Fid=3D3D34=
38=26op=3D3Dclick
=3E =3E =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=
=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=

=3E =3E Springframework-developer mailing list
=3E =3E Springframework-developer=40lists=2Esourceforge=2Enet
=3E =3E https=3A//lists=2Esourceforge=2Enet/lists/listinfo/springframewor=
k-
=3E developer=3E =

=3E =3E =

=3E =3E =

=3E =3E =

=3E =3E -------------------------------------------------------
=3E =3E SF=2ENet is sponsored by=3A Speed Start Your Linux Apps Now=2E
=3E =3E Build and deploy apps =26 Web services for Linux with
=3E =3E a free DVD software kit from IBM=2E Click Now!
=3E =3E http=3A//ads=2Eosdn=2Ecom/=3Fad=5Fid=3D1356=26alloc=5Fid=3D3438=26=
op=3Dclick
=3E =3E =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=
=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=

=3E =3E Springframework-developer mailing list
=3E =3E Springframework-developer=40lists=2Esourceforge=2Enet
=3E =3E https=3A//lists=2Esourceforge=2Enet/lists/listinfo/springframewor=
k-
=3E developer=3E =

=3E =

=3E =

=3E =

=3E =

=3E =

=3E -------------------------------------------------------
=3E SF=2ENet is sponsored by=3A Speed Start Your Linux Apps Now=2E
=3E Build and deploy apps =26 Web services for Linux with
=3E a free DVD software kit from IBM=2E Click Now!
=3E http=3A//ads=2Eosdn=2Ecom/=3Fad=5Fid=3D1356=26alloc=5Fid=3D3438=26op=3D=
click
=3E =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=
=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F
=3E Springframework-developer mailing list
=3E Springframework-developer=40lists=2Esourceforge=2Enet
=3E https=3A//lists=2Esourceforge=2Enet/lists/listinfo/springframework-de=
veloper
=3E 

Re: [Springframework-developer] DataFieldMaxValueIncrementer

[<jue...@we...>]

Okidoki, but I don't think that we need a separate JdbcResourceException =
class here - I've just changed it back to =
CannotGetJdbcConnectionException, like it initially was (good that I =
haven't committed it yet ;-). Given that we use a DataAccessException, =
CannotGetJdbcConnectionException seems to be good enough.
=20
I'm also not keen on changing the names of the exception base classes. =
Granted, "ResourceFailureException" sounds like a double negative, but =
it helps to distinguish it from "ResourceUsageException": in the former =
case, the resource itself failed; in the latter case, it was used =
inappropriately.
=20
Juergen
=20

________________________________

Von: spr...@li... im Auftrag =
von tri...@tr...
Gesendet: Sa 28.02.2004 23:08
An: spr...@li...
Betreff: Re: [Springframework-developer] DataFieldMaxValueIncrementer




It's not necessarily a bad argument though - it could just be that the =
runtime
environment is misconfigured - I think a JdbcResourceException (see =
previous
email) would be appropriate.

Thomas

Quoting "j=FCrgen h=F6ller [werk3AT]" <jue...@we...>:

> But the javax.sql.DataSource interface is plain JDBC, typically to be =
=3D
> used by Spring DAOs just like any other DataSource. It's getConnection =
=3D
> methods throw SQLException, according to the DataSource interface.
> =3D20
> This is about *setting up* a DriverManagerDataSource; I don't see why =
=3D
> setDriverClassName or the constructor should throw a =
DataAccessException =3D
> here. Other Spring beans - including DAO support classes - throw =3D
> IllegalArgumentException or the like too when they get bad =
configuration =3D
> parameters on initialization.
> =3D20
> As I said, I changed DriverManagerDataSource initialization to throw =
=3D
> IllegalArgumentException, after Thomas' remark. The kind of unchecked =
=3D
> exception thrown on initialization is a rather academic issue... In =
=3D
> particular, if the driver class name isn't right, you can't do =
anything =3D
> meaningful anyway.
> =3D20
> Juergen
> =3D20
>
> ________________________________
>
> Von: spr...@li... im Auftrag =
=3D
> von Rod Johnson
> Gesendet: Sa 28.02.2004 22:33
> An: spr...@li...
> Betreff: Re: [Springframework-developer] DataFieldMaxValueIncrementer
>
>
>
>
>
>
> >Good point - changed to IllegalArgumentException.
>
> >I just didn't want to throw CannotGetJdbcConnectionException like =3D
> before;
> it arguably wasn't appropriate. In general. the DataSource =3D
> implementations
> shouldn't use DataAccessExceptions in the first place.
>
> I disagree. I think that the user should be able to catch
> DataAccessException confidently in all cases (which was why I changed =
=3D
> from
> ClassNotFoundException to a DataAccessException).
>
> I don't have terribly strong views on this as it's not a production =
=3D
> usage
> class anyway--but that also implies it wasn't really worth changing =
the
> behaviour either...
>
>
>
>
> -------------------------------------------------------
> SF.Net is sponsored by: Speed Start Your Linux Apps Now.
> Build and deploy apps & Web services for Linux with
> a free DVD software kit from IBM. Click Now!
> http://ads.osdn.com/?ad_id=3D3D1356&alloc_id=3D3D3438&op=3D3Dclick
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>
>
>
>
> -------------------------------------------------------
> SF.Net is sponsored by: Speed Start Your Linux Apps Now.
> Build and deploy apps & Web services for Linux with
> a free DVD software kit from IBM. Click Now!
> http://ads.osdn.com/?ad_id=3D1356&alloc_id=3D3438&op=3Dclick
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>





-------------------------------------------------------
SF.Net is sponsored by: Speed Start Your Linux Apps Now.
Build and deploy apps & Web services for Linux with
a free DVD software kit from IBM. Click Now!
http://ads.osdn.com/?ad_id=3D1356&alloc_id=3D3438&op=3Dclick
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

Re: [Springframework-developer] DataFieldMaxValueIncrementer

[Rod J. <rod...@in...>]

>I'm also not keen on changing the names of the exception base classes

Agree.

----- Original Message -----
From: "j=FCrgen h=F6ller [werk3AT]" <jue...@we...>
To: <spr...@li...>
Sent: Saturday, February 28, 2004 10:46 PM
Subject: Re: [Springframework-developer] DataFieldMaxValueIncrementer


Okidoki, but I don't think that we need a separate JdbcResourceException
class here - I've just changed it back to CannotGetJdbcConnectionExceptio=
n,
like it initially was (good that I haven't committed it yet ;-). Given th=
at
we use a DataAccessException, CannotGetJdbcConnectionException seems to b=
e
good enough.

I'm also not keen on changing the names of the exception base classes.
Granted, "ResourceFailureException" sounds like a double negative, but it
helps to distinguish it from "ResourceUsageException": in the former case=
,
the resource itself failed; in the latter case, it was used inappropriate=
ly.

Juergen


________________________________

Von: spr...@li... im Auftrag von
tri...@tr...
Gesendet: Sa 28.02.2004 23:08
An: spr...@li...
Betreff: Re: [Springframework-developer] DataFieldMaxValueIncrementer




It's not necessarily a bad argument though - it could just be that the
runtime
environment is misconfigured - I think a JdbcResourceException (see previ=
ous
email) would be appropriate.

Thomas

Quoting "j=FCrgen h=F6ller [werk3AT]" <jue...@we...>:

> But the javax.sql.DataSource interface is plain JDBC, typically to be =3D
> used by Spring DAOs just like any other DataSource. It's getConnection =
=3D
> methods throw SQLException, according to the DataSource interface.
> =3D20
> This is about *setting up* a DriverManagerDataSource; I don't see why =3D
> setDriverClassName or the constructor should throw a DataAccessExceptio=
n =3D
> here. Other Spring beans - including DAO support classes - throw =3D
> IllegalArgumentException or the like too when they get bad configuratio=
n =3D
> parameters on initialization.
> =3D20
> As I said, I changed DriverManagerDataSource initialization to throw =3D
> IllegalArgumentException, after Thomas' remark. The kind of unchecked =3D
> exception thrown on initialization is a rather academic issue... In =3D
> particular, if the driver class name isn't right, you can't do anything=
 =3D
> meaningful anyway.
> =3D20
> Juergen
> =3D20
>
> ________________________________
>
> Von: spr...@li... im Auftrag =3D
> von Rod Johnson
> Gesendet: Sa 28.02.2004 22:33
> An: spr...@li...
> Betreff: Re: [Springframework-developer] DataFieldMaxValueIncrementer
>
>
>
>
>
>
> >Good point - changed to IllegalArgumentException.
>
> >I just didn't want to throw CannotGetJdbcConnectionException like =3D
> before;
> it arguably wasn't appropriate. In general. the DataSource =3D
> implementations
> shouldn't use DataAccessExceptions in the first place.
>
> I disagree. I think that the user should be able to catch
> DataAccessException confidently in all cases (which was why I changed =3D
> from
> ClassNotFoundException to a DataAccessException).
>
> I don't have terribly strong views on this as it's not a production =3D
> usage
> class anyway--but that also implies it wasn't really worth changing the
> behaviour either...
>
>
>
>
> -------------------------------------------------------
> SF.Net is sponsored by: Speed Start Your Linux Apps Now.
> Build and deploy apps & Web services for Linux with
> a free DVD software kit from IBM. Click Now!
> http://ads.osdn.com/?ad_id=3D3D1356&alloc_id=3D3D3438&op=3D3Dclick
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>
>
>
>
> -------------------------------------------------------
> SF.Net is sponsored by: Speed Start Your Linux Apps Now.
> Build and deploy apps & Web services for Linux with
> a free DVD software kit from IBM. Click Now!
> http://ads.osdn.com/?ad_id=3D1356&alloc_id=3D3438&op=3Dclick
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>





-------------------------------------------------------
SF.Net is sponsored by: Speed Start Your Linux Apps Now.
Build and deploy apps & Web services for Linux with
a free DVD software kit from IBM. Click Now!
http://ads.osdn.com/?ad_id=3D1356&alloc_id=3D3438&op=3Dclick
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer




-------------------------------------------------------
SF.Net is sponsored by: Speed Start Your Linux Apps Now.
Build and deploy apps & Web services for Linux with
a free DVD software kit from IBM. Click Now!
http://ads.osdn.com/?ad_id=1356&alloc_id438&op=3Dick
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer