Menu
▾
▴
springframework-developer — Spring Framework developers list
You can subscribe to this list here.
| 2003 |
Jan
|
Feb
(55) |
Mar
(100) |
Apr
(203) |
May
(330) |
Jun
(190) |
Jul
(302) |
Aug
(323) |
Sep
(197) |
Oct
(245) |
Nov
(490) |
Dec
(330) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2004 |
Jan
(194) |
Feb
(400) |
Mar
(416) |
Apr
(415) |
May
(359) |
Jun
(381) |
Jul
(491) |
Aug
(311) |
Sep
(291) |
Oct
(273) |
Nov
(355) |
Dec
(266) |
| 2005 |
Jan
(306) |
Feb
(303) |
Mar
(520) |
Apr
(346) |
May
(255) |
Jun
(221) |
Jul
(171) |
Aug
(247) |
Sep
(147) |
Oct
(125) |
Nov
(165) |
Dec
(65) |
| 2006 |
Jan
(90) |
Feb
(53) |
Mar
(121) |
Apr
(103) |
May
(113) |
Jun
(103) |
Jul
(104) |
Aug
(67) |
Sep
(78) |
Oct
(82) |
Nov
(78) |
Dec
(70) |
| 2007 |
Jan
(77) |
Feb
(76) |
Mar
(63) |
Apr
(30) |
May
(47) |
Jun
(41) |
Jul
(44) |
Aug
(44) |
Sep
(49) |
Oct
(33) |
Nov
(25) |
Dec
(21) |
| 2008 |
Jan
(45) |
Feb
(13) |
Mar
(15) |
Apr
(12) |
May
(9) |
Jun
(33) |
Jul
(30) |
Aug
(7) |
Sep
(20) |
Oct
(17) |
Nov
(20) |
Dec
(10) |
| 2009 |
Jan
(8) |
Feb
(5) |
Mar
(12) |
Apr
(17) |
May
(19) |
Jun
(97) |
Jul
(77) |
Aug
(33) |
Sep
(24) |
Oct
(41) |
Nov
(16) |
Dec
(32) |
| 2010 |
Jan
(24) |
Feb
(14) |
Mar
(50) |
Apr
(71) |
May
(70) |
Jun
(64) |
Jul
(45) |
Aug
(62) |
Sep
(32) |
Oct
(4) |
Nov
(12) |
Dec
(2) |
| 2011 |
Jan
(1) |
Feb
(3) |
Mar
(4) |
Apr
(3) |
May
(6) |
Jun
(1) |
Jul
(4) |
Aug
(3) |
Sep
(4) |
Oct
(6) |
Nov
(3) |
Dec
(3) |
| 2012 |
Jan
(4) |
Feb
(8) |
Mar
(6) |
Apr
(10) |
May
(2) |
Jun
(3) |
Jul
(11) |
Aug
(10) |
Sep
(4) |
Oct
|
Nov
(1) |
Dec
(1) |
| 2013 |
Jan
(4) |
Feb
(1) |
Mar
(9) |
Apr
(1) |
May
(8) |
Jun
(2) |
Jul
(5) |
Aug
(2) |
Sep
|
Oct
(3) |
Nov
(10) |
Dec
(8) |
| 2014 |
Jan
(3) |
Feb
(12) |
Mar
(9) |
Apr
(12) |
May
(2) |
Jun
|
Jul
(3) |
Aug
(1) |
Sep
(1) |
Oct
(4) |
Nov
|
Dec
(2) |
| 2015 |
Jan
(1) |
Feb
(3) |
Mar
(4) |
Apr
(9) |
May
(2) |
Jun
(2) |
Jul
|
Aug
(2) |
Sep
(7) |
Oct
(9) |
Nov
(7) |
Dec
(9) |
| 2016 |
Jan
(7) |
Feb
(5) |
Mar
(5) |
Apr
(5) |
May
(8) |
Jun
(4) |
Jul
(5) |
Aug
(4) |
Sep
(6) |
Oct
(7) |
Nov
(2) |
Dec
(3) |
| 2017 |
Jan
(7) |
Feb
(8) |
Mar
(7) |
Apr
(3) |
May
(4) |
Jun
(3) |
Jul
(5) |
Aug
(8) |
Sep
(4) |
Oct
(2) |
Nov
(3) |
Dec
|
| 2018 |
Jan
|
Feb
|
Mar
|
Apr
(1) |
May
|
Jun
(1) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(1) |
Dec
|
| 2019 |
Jan
|
Feb
(1) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(1) |
| 2021 |
Jan
|
Feb
(1) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2022 |
Jan
|
Feb
(1) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(1) |
Oct
|
Nov
|
Dec
|
| 2024 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(1) |
Dec
|
| 2025 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(1) |
Jun
|
Jul
(2) |
Aug
(5) |
Sep
(2) |
Oct
|
Nov
|
Dec
(1) |
| 2026 |
Jan
(1) |
Feb
|
Mar
(1) |
Apr
|
May
|
Jun
|
Jul
(1) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: <jue...@we...> - 2003-05-25 21:30:31
|
SGkgZXZlcnlvbmUsDQogDQpJIGp1c3QgaGFkIGEgbG9vayBhdCBKMkVFIDEuNCdzIEpBQ0MgKEph dmEgQXV0aG9yaXphdGlvbiBDb250cmFjdCBmb3IgQ29udGFpbmVycyksIGFuZCBJJ20gZGlzYXBw b2ludGVkLiBXZWxsLCBpdCBkZWFscyB3aXRoIGF1dGhvcml6YXRpb24gb2Ygd2ViIGFuZCBFSkIg cmVzb3VyY2VzLCB3aGF0IGVsc2Ugd291bGQgeW91IGV4cGVjdCBmcm9tIHRoYXQgbmFtZT8gQnV0 IHdobyBuZWVkcyB0aGF0LCBkZXBsb3ltZW50IGRlc2NyaXB0b3JzIGFsbG93IHRvIHNwZWNpZnkg cmVzb3VyY2UgYXV0aG9yaXphdGlvbiBpbiBhIGdvb2QgZW5vdWdoIHdheSBhbHJlYWR5LCBlLmcu IGluIHdlYi54bWwuDQogDQpXaGF0IEkgcmVhbGx5IG1pc3MgaXMgcG9ydGFibGUgYXV0aGVudGlj YXRpb24uIEV2ZXJ5IGZyZWFraW5nIGNvbnRhaW5lciBoYXMgaXRzIG93biBBUEkgZm9yIGF1dGhl bnRpY2F0b3JzLCBiYXNpY2FsbHkgdGFraW5nIHVzZXJuYW1lIGFuZCBwYXNzd29yZCwgYW5kIHJl dHVybmluZyB0aGUgcm9sZXMgZm9yIHRoaXMgdXNlciwgaWYgYW55LiBPZiBjb3Vyc2UsIHRoZXJl IGFyZSBhbHdheXMgZGVmYXVsdCBpbXBsZW1lbnRhdGlvbnMgZm9yIFhNTCBmaWxlcyBhbmQgZGF0 YWJhc2UgdGFibGVzLiBCdXQgeW91J2xsIGhhdmUgdG8gZ2V0IGNvbnRhaW5lci1zcGVjaWZpYyB0 byB1c2UgdGhlIEoyRUUgbG9naW4gaW5mcmFzdHJ1Y3R1cmUgaW4geW91ciBhcHBzIGlmIHlvdSBr ZWVwIHRoZSB1c2VyIGRhdGEgaW4geW91ciBhcHBsaWNhdGlvbiBkYXRhYmFzZSwgb3Igc29tZSBv dGhlciBhcHBsaWNhdGlvbi1zcGVjaWZpYyBkYXRhc3RvcmUuDQogDQpGdXJ0aGVybW9yZSwgYSBK MkVFIHdlYiBsb2dpbiBzaW1wbHkgYXV0aGVudGljYXRlcyBhbmQgcmV0dXJucyB0byB0aGUgb3Jp Z2luYWwgVVJMIGlmIHRoZSB1c2VyIGlzIGF1dGhvcml6ZWQuIE9uIGVhY2ggZm9sbG93aW5nIFVS TCwgdGhlIGF1dGhvcml6YXRpb24gY2hlY2sgaGFwcGVucyBhZ2FpbiwgZm9yYmlkZGluZyBhY2Nl c3MgaWYgdGhlIHVzZXIgaXNuJ3QgaW4gYW4gYXBwcm9wcmlhdGUgcm9sZS4gT2YgY291cnNlLCBz ZXJ2bGV0cyBjYW4gcHJvZ3JhbW1hdGljYWxseSBhY2Nlc3MgdGhlIHVzZXIgbmFtZSwgYW5kIGNo ZWNrIGlmIHRoZSBjdXJyZW50IHVzZXIgaXMgYSBnaXZlbiByb2xlIC0gYnV0IHRoYXQncyBpdC4g VGhlcmUgYXJlIG5vIGhvb2tzIGZvciBsb2FkaW5nIHVzZXItc3BlY2lmaWMgc2V0dGluZ3Mgb24g bG9naW4sIGZvciBleGFtcGxlLg0KIA0KVGh1cywgSjJFRSBhdXRoZW50aWNhdGlvbiBzZWVtcyBv bmx5IHVzYWJsZSBmb3IgYmFzaWMgd2Vic2l0ZSBhZG1pbmlzdHJhdGlvbiBwdXJwb3NlcywgbGlr ZSByZXN0cmljdGluZyBjZXJ0YWluIG5hbWVzcGFjZXMgZm9yIGFkbWluaXN0cmF0b3JzIG9ubHks IHNwZWNpZnlpbmcgdGhlIGFkbWluaXN0cmF0b3IgdXNlcm5hbWVzIGFuZCBwYXNzd29yZHMgaW4g YSBzZXJ2ZXItc3BlY2lmaWMgd2F5LiBJdCdzIGNvbXBsZXRlbHkgaW5hcHByb3ByaWF0ZSBmb3Ig aGFuZGxpbmcgYSB0aWdodGx5IGludGVncmF0ZWQgYXBwbGljYXRpb24gdXNlciBiYXNlLCBwb3Rl bnRpYWxseSB3aXRoIHRob3VzYW5kcyBvZiBjdXN0b21pemVkIHVzZXJzLg0KIA0KV2h5PyBUaGUg SjJFRSBtb2RlbCBkb2Vzbid0IHJlYWxseSBmaXQgdGhlIGNvbmNlcHQgb2YgYSBsb2dpbiBpbnRv IGEgcmljaCB3ZWIgYXBwbGljYXRpb24uIFR5cGljYWxseSwgYSBsb2dpbiBwYWdlIGlzIGVpdGhl ciB0aGUgc3RhcnRpbmcgcG9pbnQsIG9yIHJlcXVpcmVkIGZvciBzb21lIHBhcnRzIG9mIHRoZSBh cHBsaWNhdGlvbi4gT24gbG9naW4sIHVzZXIgc2V0dGluZ3MgZ2V0IGxvYWRlZCBhbmQgcHV0IGlu IHRoZSBzZXNzaW9uLiBXZWIgY29udHJvbGxlcnMgb2ZmZW4gYWN0IGFjY29yZGluZyB0byB0aGVz ZSB1c2VyIHNldHRpbmdzLCBvciBhcmUgZm9yYmlkZGVuIHdpdGhvdXQgbG9naW4uIEEgbG9nb3V0 IGVpdGhlciByZW1vdmVzIHRoZSB1c2VyIHNldHRpbmdzIGZyb20gdGhlIHNlc3Npb24sIHRoZWly IGV4aXN0ZW5jZSBiZWluZyByZWxhdGVkIHRvIHRoZSBsb2dpbiBzdGF0dXMsIG9yIGludmFsaWRh dGVzIHRoZSBzZXNzaW9uLg0KIA0KQWxsIHRoaW5ncyBjb25zaWRlcmVkLCBpdCB3b3VsZCBtYWtl IHNlbnNlIHRvIG9mZmVyIGF1dGhlbnRpY2F0aW9uIHN1cHBvcnQgd2l0aGluIFNwcmluZydzIHdl YiBNVkMuIFRoZSBiYXNpYyByZXF1aXJlbWVudHMgYXJlIHRoZSBvbmVzIGZyb20gdGhlIGxhc3Qg cGFyYWdyYXBoLiBPZiBjb3Vyc2UsIGl0IGlzIGFscmVhZHkgcG9zc2libGUgdG8gaW1wbGVtZW50 IHRoaXMgdmlhIGEgY3VzdG9tIExvZ2luQ29udHJvbGxlciwgY2hlY2tpbmcgYSBsb2dpbi9sb2dv dXQgcmVxdWVzdCBhbmQgaGFuZGxpbmcgdGhlIHVzZXIgc2V0dGluZ3MgaW4gdGhlIHNlc3Npb24s IGFuZCByZXNwZWN0aXZlIGNoZWNrcyBpbiBidXNpbmVzcyBjb250cm9sbGVycy4gSSBqdXN0IHdv bmRlciBpZiB3ZSBjb3VsZCBvZmZlciBkZWRpY2F0ZWQgYXV0aGVudGljYXRpb24gc3VwcG9ydCB0 byBlYXNlIHRoZSB0YXNrLg0KIA0KUmVnYXJkcywNCkp1ZXJnZW4NCg== |
|
From: JP P. <jp....@ti...> - 2003-05-25 19:43:30
|
Hi everybody, I was disappointed that Rod's book was not in the finalist's list. I have no regret as I voted for. In the three nominated books, I only bought and have read Martin Fowler's one. I have to say that it's effectively also a great book to recommend. Regards, ______________________________=A0 Jean-Pierre Pawlak jp....@ti... =A0 |
|
From: JP P. <jp....@ti...> - 2003-05-25 19:19:55
|
Hi Isabelle, It is effectively the way I suggested. You made also a great job about multithreading. But I have still the same issue. How setting, in practice, for run the live tests. I didn't look for now at the batch you sent to Rod. Is it currently up to date or is a newer way? Regards, Jean-Pierre > -----Message d'origine----- > De=A0: spr...@li... > [mailto:spr...@li...] De la part > de Isabelle Muszynski > Envoy=E9=A0: dimanche 25 mai 2003 18:29 > =C0=A0: spr...@li... > Objet=A0: [Springframework-developer] mysql key generation >=20 > Hi everyone, >=20 > I've rewritten mySQL key generation (MySQLMaxValueIncrementer.java). > KeyBinder is no longer used. For a sample of how to use key generation, > have a look at livetest/JdbcInsertTestSuite.java. >=20 > Your main table (the one for which you want key generation) should not > auto_increment its key. The sequence table, on the other hand, should be > auto_increment. Have a look at createTables in JdbcInsertTestSuite or at > the javadoc for MySQLMaxValueIncrementer.java. >=20 > Please let me know if there still are problems. One of the tests is for > behavior when multithreading, and on my system it succeeds. >=20 > Isabelle >=20 > -- > Isabelle Muszynski > Software Engineer > Zandweellaan 4 > 2660 Antwerpen > Belgium > Tel. 32-(0)3-830 18 54 > Mobile: 32-(0)485 49 50 89 > Email: isa...@me... > Website: www.meta-logix.com >=20 >=20 > ------------------------------------------------------- > This SF.net email is sponsored by: ObjectStore. > If flattening out C++ or Java code to make your application fit in a > relational database is painful, don't do it! Check out ObjectStore. > Now part of Progress Software. http://www.objectstore.net/sourceforge > _______________________________________________ > Springframework-developer mailing list > Spr...@li... > https://lists.sourceforge.net/lists/listinfo/springframework-developer |
|
From: Isabelle M. <isa...@me...> - 2003-05-25 16:28:56
|
Hi everyone, I've rewritten mySQL key generation (MySQLMaxValueIncrementer.java). KeyBinder is no longer used. For a sample of how to use key generation, have a look at livetest/JdbcInsertTestSuite.java. Your main table (the one for which you want key generation) should not auto_increment its key. The sequence table, on the other hand, should be auto_increment. Have a look at createTables in JdbcInsertTestSuite or at the javadoc for MySQLMaxValueIncrementer.java. Please let me know if there still are problems. One of the tests is for behavior when multithreading, and on my system it succeeds. Isabelle -- Isabelle Muszynski Software Engineer Zandweellaan 4 2660 Antwerpen Belgium Tel. 32-(0)3-830 18 54 Mobile: 32-(0)485 49 50 89 Email: isa...@me... Website: www.meta-logix.com |
|
From: =?iso-8859-1?Q?<jp....@ti...> - 2003-05-25 13:12:44
|
Hi J=FCrgen,=0D=0A=0D=0AYour suggests are very welcome. As you have a be=
tter knowledge ob the whole Spring framework, you seen quickly better int=
eraction use. I am not at home, It seems you are already making the chang=
e. If you expext anything from me, talk me just about. =0D=0A=0D=0ARegar=
ds,=0D=0AJean-Pierre=0D=0A=0D=0A---------- Initial Header -----------=0D=0A=
=0D=0AFrom : spr...@li...=0D=
=0ATo : "JP Pawlak" <jp....@ti...>,"Spring Developers" <=
spr...@li...>=0D=0ACc : =0D=0A=
Date : Sun, 25 May 2003 14:48:34 +0200=0D=0ASubject : Re: [Springfra=
mework-developer] paged lists=0D=0A=0D=0AHi Jean-Pierre,=0D=0A =0D=0ABTW,=
the tests have all worked for me on Friday - I'll recheck tomorrow.=0D=0A=
=0D=0ARegarding PagedListAutoHolder: I appreciate its added functionalit=
y. If I understand correctly, it's targetted at easy usage in a web contr=
oller. My initial PagedListHolder was just a first take, drawn from an ap=
plication project. I'm very much for working all of this into a refined v=
ersion, even before 0.8. I'll probably use it in our application project =
too.=0D=0A =0D=0A---=0D=0A =0D=0AI've got some concrete issues:=0D=0A =0D=
=0A- Generally, we should try to use data binding wherever possible, to k=
eep the model and the actions as OO resp. bean-style as possible. I'm not=
a great fan of manual parameter parsing (have used it far too many times=
myself), be it from the ServletRequest or from a String-based parameter =
map. Spring's ServletRequestDataBinder allows for very powerful binding o=
f request parameters to bean instances, even one to request to multiple b=
eans. Manual String parameter evaluation doesn't belong in a proper model=
object, IMO.=0D=0A =0D=0A- getMaxDisplayPages, getFirstDisplayPage, getL=
astDisplayPage should probably be called getMaxLinkedPages, getFirstLinke=
dPage, getLastLinkedPage - as they aren't really displayed themselves but=
rather just linked from the currently displayed page.=0D=0A =0D=0A- I'd =
like to turn your "Sort" inner class into a generic com.interface21.beans=
.SortDefinition interface, and offer an accompanying BeanUtils.sortByProp=
erty(List,SortDefinition) method. Your current Sort implementation could =
serve as DefaultSortDefinition implementation.=0D=0A =0D=0A- As you've ad=
dressed with extendedInfo, reloading can depend on various specific param=
eters. But filtering could be based not only on per-field matching values=
but on regular expressions etc. A generic "filter" property of type Obje=
ct will allow the controller to store a state object representing the cur=
rent filter settings, combining your filterMap and extendedInfo in one ge=
neric Object. Note that PagedListHolder does not and should not need to k=
now about the semantics of "filter".=0D=0A =0D=0A- Some properties repres=
ent List meta data: "sort" of type SortDefinition, "filter" of type Objec=
t, "locale" of type Locale. These can easily be included in PagedListHold=
er, just like the linked pages support too (in the end, let's merge Paged=
ListHolder and PagedListAutoHolder - we probably don't need both). PagedL=
istSourceProvider would have a generic loadList(Object Filter, Locale loc=
ale) then.=0D=0A =0D=0A- PagedListHolder properties like pageSize, pageNr=
, maxLinkedPages should be populated via binding (that's how my initial v=
ersion was meant to be used). Let's treat PagedListHolder as a form bean,=
with request parameters getting bound to it on every submit - no String =
parameter parsing, no Integer.parseInt. The same applies to "sort" and "f=
ilter": A controller can set specific instances to the PagedListHolder in=
stance on setup. These instances can be populated via the same binding st=
ep, using nested paths like "sort.ascending" etc.=0D=0A =0D=0A- PagedList=
Holder's refresh method should do equals checks on "sort" and "filter" (u=
sing stored copies from the last refresh), and perform resorting resp. re=
loading if necessary (setting current versions as stored copies). Thus, a=
controller should invoke refresh after each bean population, i.e. on eac=
h request. A real refresh can be enforced by a respective request paramet=
er, but this should be checked by the specific web controller, triggering=
a refresh(boolean enforce) call with true then.=0D=0A =0D=0A- All things=
considered, the unified PagedListHolder will not need to know anything a=
bout request parameters. PagedListAutoHolder's xxxParam properties and it=
s quite lengthy execute method aren't necessary then, most stuff can work=
via data binding and refresh. If one wants to use different request para=
meters, one can always perform manual post-binding, but the bean property=
names should be pretty straightforward as parameter names anyway. The bi=
nding paths match the JSTL EL expressions nicely, like "sort.ascending".=0D=
=0A =0D=0A---=0D=0A =0D=0AA controller implementation is as simple as bef=
ore. It just needs to trigger the binding and call the refresh method aft=
erwards, instead of the current execute call. The respective code in your=
PagedListController example would look about as follows:=0D=0A =0D=0Apub=
lic ModelAndView showMain(HttpServletRequest request, HttpServletResponse=
response) {=0D=0A PagedListAutoHolder listHolder =3D=0D=0A (PagedLis=
tAutoHolder)request.getSession(true).getAttribute(COUNTRIES_ATTR);=0D=0A =
if (null =3D=3D listHolder) {=0D=0A listHolder =3D (PagedListAutoHold=
er)this.getApplicationContext().getBean("autoListHolder");=0D=0A listH=
older.setSourceProvider(new CountriesProvider());=0D=0A listHolder.set=
Filter(new CountriesFilter());=0D=0A listHolder.setSort(new DefaultSor=
tDefinition());=0D=0A request.getSession(true).setAttribute(COUNTRIES_=
ATTR, listHolder); =0D=0A }=0D=0A BindException ex =3D BindUtils.bind(=
request, listHolder, "countries");=0D=0A boolean forceRefresh =3D reques=
t.getParameter("forceRefresh) !=3D null;=0D=0A listHolder.refresh(forceR=
efresh);=0D=0A return new ModelAndView("mainView", ex.getModel());=0D=0A=
}=0D=0A =0D=0Apublic class CountriesFilter {=0D=0A private String name;=0D=
=0A private String code;=0D=0A public String getName() {=0D=0A retur=
n name;=0D=0A }=0D=0A public vois setName(String name) {=0D=0A this.=
name =3D name;=0D=0A }=0D=0A public String getCode() {=0D=0A return =
code;=0D=0A }=0D=0A public vois setCode(String code) {=0D=0A this.co=
de =3D code;=0D=0A }=0D=0A}=0D=0A =0D=0AFiltering doesn't work via param=
eter names that serve as filter names anymore, but with a nested "filter"=
object of type CountriesFilter. So your main.jsp would need to use "coun=
tries.filter.code" EL for matching, sending "filter.code" as request para=
meter name for changing. The same applies to sorting, using the nested "s=
ort" object: e.g. "countries.sort.ascending" EL for evaluation (just like=
in your current version), "sort.ascending" as request parameter name.=0D=
=0A =0D=0A---=0D=0A =0D=0AWhat do you think? I'm keen on applying these c=
hanges promptly, if you don't mind, if possible already tomorrow. BTW, I'=
m writing this on a non-development PC at home, so I haven't actually pro=
totyped the design, but I expect it to work nicely. We should end up with=
significantly less and more maintainable code, I hope.=0D=0A =0D=0ARegar=
ds,=0D=0AJuergen=0D=0A =0D=0A =0D=0A=0D=0A -----Urspr=FCngliche Nachricht=
----- =0D=0A Von: JP Pawlak [mailto:jp....@ti...] =0D=0A Gesendet=
: Fr 23.05.2003 22:20 =0D=0A An: Spring Developers =0D=0A Cc: =0D=0A Betr=
eff: [Springframework-developer] paged lists=0D=0A =0D=0A =0D=0A=0D=0A=0D=
=0A Hi,=0D=0A =0D=0A Excuse me from disturbing from fundamental issues li=
ke the KeyBinder=0D=0A posted by Isabelle and the broken tests I've just =
posted.=0D=0A =0D=0A As I talked about, I have added three files:=0D=0A I=
n src:=0D=0A - com.interface21.util.PagedListAutoHolder.java (Class de=
rived from=0D=0A PagedListHolder)=0D=0A - com.interface21.util.PagedLi=
stSourceProvider.java (Interface)=0D=0A in test:=0D=0A - com.interface=
21.util.PagedListAutoHolderTests.java (Class)=0D=0A =0D=0A This all for e=
asy use of a more powerfull paged List.=0D=0A The javadoc and eventually =
test source will normally suffice to=0D=0A understand the use.=0D=0A Neve=
rtheless, if I will not be impacted by the current test issues, I=0D=0A w=
ill try to provide a tiny sample application for demonstrating.=0D=0A =0D=
=0A After 0.8 will be released, I could have some help for rewieving the=0D=
=0A javadoc comments as my English is very far from perfect.=0D=0A =0D=0A=
Regards,=0D=0A ______________________________=0D=0A Jean-Pierre Pawlak=0D=
=0A jp....@ti...=0D=0A =0D=0A =0D=0A =0D=0A =0D=0A =0D=0A ------=
-------------------------------------------------=0D=0A This SF.net email=
is sponsored by: ObjectStore.=0D=0A If flattening out C++ or Java code t=
o make your application fit in a=0D=0A relational database is painful, do=
n't do it! Check out ObjectStore.=0D=0A Now part of Progress Software. ht=
tp://www.objectstore.net/sourceforge=0D=0A ______________________________=
_________________=0D=0A Springframework-developer mailing list=0D=0A Spri=
ngf...@li...=0D=0A https://lists.sourcefor=
ge.net/lists/listinfo/springframework-developer=0D=0A =0D=0A=0D=0A=0A=0A*=
********* SPECIAL ADSL **********=0AL'ADSL =E0 partir de 15,95 EUR/mois e=
t le modem ADSL offert ? C'est en exclusivit=E9 chez Tiscali !=0APour pr=
ofiter de cette offre, cliquez ici: http://register.tiscali.fr/adsl/=0AOf=
fre soumise =E0 conditions.=0A
|
|
From: <jue...@we...> - 2003-05-25 12:47:11
|
SGkgSmVhbi1QaWVycmUsDQogDQpCVFcsIHRoZSB0ZXN0cyBoYXZlIGFsbCB3b3JrZWQgZm9yIG1l IG9uIEZyaWRheSAtIEknbGwgcmVjaGVjayB0b21vcnJvdy4NCiANClJlZ2FyZGluZyBQYWdlZExp c3RBdXRvSG9sZGVyOiBJIGFwcHJlY2lhdGUgaXRzIGFkZGVkIGZ1bmN0aW9uYWxpdHkuIElmIEkg dW5kZXJzdGFuZCBjb3JyZWN0bHksIGl0J3MgdGFyZ2V0dGVkIGF0IGVhc3kgdXNhZ2UgaW4gYSB3 ZWIgY29udHJvbGxlci4gTXkgaW5pdGlhbCBQYWdlZExpc3RIb2xkZXIgd2FzIGp1c3QgYSBmaXJz dCB0YWtlLCBkcmF3biBmcm9tIGFuIGFwcGxpY2F0aW9uIHByb2plY3QuIEknbSB2ZXJ5IG11Y2gg Zm9yIHdvcmtpbmcgYWxsIG9mIHRoaXMgaW50byBhIHJlZmluZWQgdmVyc2lvbiwgZXZlbiBiZWZv cmUgMC44LiBJJ2xsIHByb2JhYmx5IHVzZSBpdCBpbiBvdXIgYXBwbGljYXRpb24gcHJvamVjdCB0 b28uDQogDQotLS0NCiANCkkndmUgZ290IHNvbWUgY29uY3JldGUgaXNzdWVzOg0KIA0KLSBHZW5l cmFsbHksIHdlIHNob3VsZCB0cnkgdG8gdXNlIGRhdGEgYmluZGluZyB3aGVyZXZlciBwb3NzaWJs ZSwgdG8ga2VlcCB0aGUgbW9kZWwgYW5kIHRoZSBhY3Rpb25zIGFzIE9PIHJlc3AuIGJlYW4tc3R5 bGUgYXMgcG9zc2libGUuIEknbSBub3QgYSBncmVhdCBmYW4gb2YgbWFudWFsIHBhcmFtZXRlciBw YXJzaW5nIChoYXZlIHVzZWQgaXQgZmFyIHRvbyBtYW55IHRpbWVzIG15c2VsZiksIGJlIGl0IGZy b20gdGhlIFNlcnZsZXRSZXF1ZXN0IG9yIGZyb20gYSBTdHJpbmctYmFzZWQgcGFyYW1ldGVyIG1h cC4gU3ByaW5nJ3MgU2VydmxldFJlcXVlc3REYXRhQmluZGVyIGFsbG93cyBmb3IgdmVyeSBwb3dl cmZ1bCBiaW5kaW5nIG9mIHJlcXVlc3QgcGFyYW1ldGVycyB0byBiZWFuIGluc3RhbmNlcywgZXZl biBvbmUgdG8gcmVxdWVzdCB0byBtdWx0aXBsZSBiZWFucy4gTWFudWFsIFN0cmluZyBwYXJhbWV0 ZXIgZXZhbHVhdGlvbiBkb2Vzbid0IGJlbG9uZyBpbiBhIHByb3BlciBtb2RlbCBvYmplY3QsIElN Ty4NCiANCi0gZ2V0TWF4RGlzcGxheVBhZ2VzLCBnZXRGaXJzdERpc3BsYXlQYWdlLCBnZXRMYXN0 RGlzcGxheVBhZ2Ugc2hvdWxkIHByb2JhYmx5IGJlIGNhbGxlZCBnZXRNYXhMaW5rZWRQYWdlcywg Z2V0Rmlyc3RMaW5rZWRQYWdlLCBnZXRMYXN0TGlua2VkUGFnZSAtIGFzIHRoZXkgYXJlbid0IHJl YWxseSBkaXNwbGF5ZWQgdGhlbXNlbHZlcyBidXQgcmF0aGVyIGp1c3QgbGlua2VkIGZyb20gdGhl IGN1cnJlbnRseSBkaXNwbGF5ZWQgcGFnZS4NCiANCi0gSSdkIGxpa2UgdG8gdHVybiB5b3VyICJT b3J0IiBpbm5lciBjbGFzcyBpbnRvIGEgZ2VuZXJpYyBjb20uaW50ZXJmYWNlMjEuYmVhbnMuU29y dERlZmluaXRpb24gaW50ZXJmYWNlLCBhbmQgb2ZmZXIgYW4gYWNjb21wYW55aW5nIEJlYW5VdGls cy5zb3J0QnlQcm9wZXJ0eShMaXN0LFNvcnREZWZpbml0aW9uKSBtZXRob2QuIFlvdXIgY3VycmVu dCBTb3J0IGltcGxlbWVudGF0aW9uIGNvdWxkIHNlcnZlIGFzIERlZmF1bHRTb3J0RGVmaW5pdGlv biBpbXBsZW1lbnRhdGlvbi4NCiANCi0gQXMgeW91J3ZlIGFkZHJlc3NlZCB3aXRoIGV4dGVuZGVk SW5mbywgcmVsb2FkaW5nIGNhbiBkZXBlbmQgb24gdmFyaW91cyBzcGVjaWZpYyBwYXJhbWV0ZXJz LiBCdXQgZmlsdGVyaW5nIGNvdWxkIGJlIGJhc2VkIG5vdCBvbmx5IG9uIHBlci1maWVsZCBtYXRj aGluZyB2YWx1ZXMgYnV0IG9uIHJlZ3VsYXIgZXhwcmVzc2lvbnMgZXRjLiBBIGdlbmVyaWMgImZp bHRlciIgcHJvcGVydHkgb2YgdHlwZSBPYmplY3Qgd2lsbCBhbGxvdyB0aGUgY29udHJvbGxlciB0 byBzdG9yZSBhIHN0YXRlIG9iamVjdCByZXByZXNlbnRpbmcgdGhlIGN1cnJlbnQgZmlsdGVyIHNl dHRpbmdzLCBjb21iaW5pbmcgeW91ciBmaWx0ZXJNYXAgYW5kIGV4dGVuZGVkSW5mbyBpbiBvbmUg Z2VuZXJpYyBPYmplY3QuIE5vdGUgdGhhdCBQYWdlZExpc3RIb2xkZXIgZG9lcyBub3QgYW5kIHNo b3VsZCBub3QgbmVlZCB0byBrbm93IGFib3V0IHRoZSBzZW1hbnRpY3Mgb2YgImZpbHRlciIuDQog DQotIFNvbWUgcHJvcGVydGllcyByZXByZXNlbnQgTGlzdCBtZXRhIGRhdGE6ICJzb3J0IiBvZiB0 eXBlIFNvcnREZWZpbml0aW9uLCAiZmlsdGVyIiBvZiB0eXBlIE9iamVjdCwgImxvY2FsZSIgb2Yg dHlwZSBMb2NhbGUuIFRoZXNlIGNhbiBlYXNpbHkgYmUgaW5jbHVkZWQgaW4gUGFnZWRMaXN0SG9s ZGVyLCBqdXN0IGxpa2UgdGhlIGxpbmtlZCBwYWdlcyBzdXBwb3J0IHRvbyAoaW4gdGhlIGVuZCwg bGV0J3MgbWVyZ2UgUGFnZWRMaXN0SG9sZGVyIGFuZCBQYWdlZExpc3RBdXRvSG9sZGVyIC0gd2Ug cHJvYmFibHkgZG9uJ3QgbmVlZCBib3RoKS4gUGFnZWRMaXN0U291cmNlUHJvdmlkZXIgd291bGQg aGF2ZSBhIGdlbmVyaWMgbG9hZExpc3QoT2JqZWN0IEZpbHRlciwgTG9jYWxlIGxvY2FsZSkgdGhl bi4NCiANCi0gUGFnZWRMaXN0SG9sZGVyIHByb3BlcnRpZXMgbGlrZSBwYWdlU2l6ZSwgcGFnZU5y LCBtYXhMaW5rZWRQYWdlcyBzaG91bGQgYmUgcG9wdWxhdGVkIHZpYSBiaW5kaW5nICh0aGF0J3Mg aG93IG15IGluaXRpYWwgdmVyc2lvbiB3YXMgbWVhbnQgdG8gYmUgdXNlZCkuIExldCdzIHRyZWF0 IFBhZ2VkTGlzdEhvbGRlciBhcyBhIGZvcm0gYmVhbiwgd2l0aCByZXF1ZXN0IHBhcmFtZXRlcnMg Z2V0dGluZyBib3VuZCB0byBpdCBvbiBldmVyeSBzdWJtaXQgLSBubyBTdHJpbmcgcGFyYW1ldGVy IHBhcnNpbmcsIG5vIEludGVnZXIucGFyc2VJbnQuIFRoZSBzYW1lIGFwcGxpZXMgdG8gInNvcnQi IGFuZCAiZmlsdGVyIjogQSBjb250cm9sbGVyIGNhbiBzZXQgc3BlY2lmaWMgaW5zdGFuY2VzIHRv IHRoZSBQYWdlZExpc3RIb2xkZXIgaW5zdGFuY2Ugb24gc2V0dXAuIFRoZXNlIGluc3RhbmNlcyBj YW4gYmUgcG9wdWxhdGVkIHZpYSB0aGUgc2FtZSBiaW5kaW5nIHN0ZXAsIHVzaW5nIG5lc3RlZCBw YXRocyBsaWtlICJzb3J0LmFzY2VuZGluZyIgZXRjLg0KIA0KLSBQYWdlZExpc3RIb2xkZXIncyBy ZWZyZXNoIG1ldGhvZCBzaG91bGQgZG8gZXF1YWxzIGNoZWNrcyBvbiAic29ydCIgYW5kICJmaWx0 ZXIiICh1c2luZyBzdG9yZWQgY29waWVzIGZyb20gdGhlIGxhc3QgcmVmcmVzaCksIGFuZCBwZXJm b3JtIHJlc29ydGluZyByZXNwLiByZWxvYWRpbmcgaWYgbmVjZXNzYXJ5IChzZXR0aW5nIGN1cnJl bnQgdmVyc2lvbnMgYXMgc3RvcmVkIGNvcGllcykuIFRodXMsIGEgY29udHJvbGxlciBzaG91bGQg aW52b2tlIHJlZnJlc2ggYWZ0ZXIgZWFjaCBiZWFuIHBvcHVsYXRpb24sIGkuZS4gb24gZWFjaCBy ZXF1ZXN0LiBBIHJlYWwgcmVmcmVzaCBjYW4gYmUgZW5mb3JjZWQgYnkgYSByZXNwZWN0aXZlIHJl cXVlc3QgcGFyYW1ldGVyLCBidXQgdGhpcyBzaG91bGQgYmUgY2hlY2tlZCBieSB0aGUgc3BlY2lm aWMgd2ViIGNvbnRyb2xsZXIsIHRyaWdnZXJpbmcgYSByZWZyZXNoKGJvb2xlYW4gZW5mb3JjZSkg Y2FsbCB3aXRoIHRydWUgdGhlbi4NCiANCi0gQWxsIHRoaW5ncyBjb25zaWRlcmVkLCB0aGUgdW5p ZmllZCBQYWdlZExpc3RIb2xkZXIgd2lsbCBub3QgbmVlZCB0byBrbm93IGFueXRoaW5nIGFib3V0 IHJlcXVlc3QgcGFyYW1ldGVycy4gUGFnZWRMaXN0QXV0b0hvbGRlcidzIHh4eFBhcmFtIHByb3Bl cnRpZXMgYW5kIGl0cyBxdWl0ZSBsZW5ndGh5IGV4ZWN1dGUgbWV0aG9kIGFyZW4ndCBuZWNlc3Nh cnkgdGhlbiwgbW9zdCBzdHVmZiBjYW4gd29yayB2aWEgZGF0YSBiaW5kaW5nIGFuZCByZWZyZXNo LiBJZiBvbmUgd2FudHMgdG8gdXNlIGRpZmZlcmVudCByZXF1ZXN0IHBhcmFtZXRlcnMsIG9uZSBj YW4gYWx3YXlzIHBlcmZvcm0gbWFudWFsIHBvc3QtYmluZGluZywgYnV0IHRoZSBiZWFuIHByb3Bl cnR5IG5hbWVzIHNob3VsZCBiZSBwcmV0dHkgc3RyYWlnaHRmb3J3YXJkIGFzIHBhcmFtZXRlciBu YW1lcyBhbnl3YXkuIFRoZSBiaW5kaW5nIHBhdGhzIG1hdGNoIHRoZSBKU1RMIEVMIGV4cHJlc3Np b25zIG5pY2VseSwgbGlrZSAic29ydC5hc2NlbmRpbmciLg0KIA0KLS0tDQogDQpBIGNvbnRyb2xs ZXIgaW1wbGVtZW50YXRpb24gaXMgYXMgc2ltcGxlIGFzIGJlZm9yZS4gSXQganVzdCBuZWVkcyB0 byB0cmlnZ2VyIHRoZSBiaW5kaW5nIGFuZCBjYWxsIHRoZSByZWZyZXNoIG1ldGhvZCBhZnRlcndh cmRzLCBpbnN0ZWFkIG9mIHRoZSBjdXJyZW50IGV4ZWN1dGUgY2FsbC4gVGhlIHJlc3BlY3RpdmUg Y29kZSBpbiB5b3VyIFBhZ2VkTGlzdENvbnRyb2xsZXIgZXhhbXBsZSB3b3VsZCBsb29rIGFib3V0 IGFzIGZvbGxvd3M6DQogDQpwdWJsaWMgTW9kZWxBbmRWaWV3IHNob3dNYWluKEh0dHBTZXJ2bGV0 UmVxdWVzdCByZXF1ZXN0LCBIdHRwU2VydmxldFJlc3BvbnNlIHJlc3BvbnNlKSB7DQogIFBhZ2Vk TGlzdEF1dG9Ib2xkZXIgbGlzdEhvbGRlciA9DQogICAgKFBhZ2VkTGlzdEF1dG9Ib2xkZXIpcmVx dWVzdC5nZXRTZXNzaW9uKHRydWUpLmdldEF0dHJpYnV0ZShDT1VOVFJJRVNfQVRUUik7DQogIGlm IChudWxsID09IGxpc3RIb2xkZXIpIHsNCiAgICBsaXN0SG9sZGVyID0gKFBhZ2VkTGlzdEF1dG9I b2xkZXIpdGhpcy5nZXRBcHBsaWNhdGlvbkNvbnRleHQoKS5nZXRCZWFuKCJhdXRvTGlzdEhvbGRl ciIpOw0KICAgIGxpc3RIb2xkZXIuc2V0U291cmNlUHJvdmlkZXIobmV3IENvdW50cmllc1Byb3Zp ZGVyKCkpOw0KICAgIGxpc3RIb2xkZXIuc2V0RmlsdGVyKG5ldyBDb3VudHJpZXNGaWx0ZXIoKSk7 DQogICAgbGlzdEhvbGRlci5zZXRTb3J0KG5ldyBEZWZhdWx0U29ydERlZmluaXRpb24oKSk7DQog ICAgcmVxdWVzdC5nZXRTZXNzaW9uKHRydWUpLnNldEF0dHJpYnV0ZShDT1VOVFJJRVNfQVRUUiwg bGlzdEhvbGRlcik7ICANCiAgfQ0KICBCaW5kRXhjZXB0aW9uIGV4ID0gQmluZFV0aWxzLmJpbmQo cmVxdWVzdCwgbGlzdEhvbGRlciwgImNvdW50cmllcyIpOw0KICBib29sZWFuIGZvcmNlUmVmcmVz aCA9IHJlcXVlc3QuZ2V0UGFyYW1ldGVyKCJmb3JjZVJlZnJlc2gpICE9IG51bGw7DQogIGxpc3RI b2xkZXIucmVmcmVzaChmb3JjZVJlZnJlc2gpOw0KICByZXR1cm4gbmV3IE1vZGVsQW5kVmlldygi bWFpblZpZXciLCBleC5nZXRNb2RlbCgpKTsNCn0NCiANCnB1YmxpYyBjbGFzcyBDb3VudHJpZXNG aWx0ZXIgew0KICBwcml2YXRlIFN0cmluZyBuYW1lOw0KICBwcml2YXRlIFN0cmluZyBjb2RlOw0K ICBwdWJsaWMgU3RyaW5nIGdldE5hbWUoKSB7DQogICAgcmV0dXJuIG5hbWU7DQogIH0NCiAgcHVi bGljIHZvaXMgc2V0TmFtZShTdHJpbmcgbmFtZSkgew0KICAgIHRoaXMubmFtZSA9IG5hbWU7DQog IH0NCiAgcHVibGljIFN0cmluZyBnZXRDb2RlKCkgew0KICAgIHJldHVybiBjb2RlOw0KICB9DQog IHB1YmxpYyB2b2lzIHNldENvZGUoU3RyaW5nIGNvZGUpIHsNCiAgICB0aGlzLmNvZGUgPSBjb2Rl Ow0KICB9DQp9DQogDQpGaWx0ZXJpbmcgZG9lc24ndCB3b3JrIHZpYSBwYXJhbWV0ZXIgbmFtZXMg dGhhdCBzZXJ2ZSBhcyBmaWx0ZXIgbmFtZXMgYW55bW9yZSwgYnV0IHdpdGggYSBuZXN0ZWQgImZp bHRlciIgb2JqZWN0IG9mIHR5cGUgQ291bnRyaWVzRmlsdGVyLiBTbyB5b3VyIG1haW4uanNwIHdv dWxkIG5lZWQgdG8gdXNlICJjb3VudHJpZXMuZmlsdGVyLmNvZGUiIEVMIGZvciBtYXRjaGluZywg c2VuZGluZyAiZmlsdGVyLmNvZGUiIGFzIHJlcXVlc3QgcGFyYW1ldGVyIG5hbWUgZm9yIGNoYW5n aW5nLiBUaGUgc2FtZSBhcHBsaWVzIHRvIHNvcnRpbmcsIHVzaW5nIHRoZSBuZXN0ZWQgInNvcnQi IG9iamVjdDogZS5nLiAiY291bnRyaWVzLnNvcnQuYXNjZW5kaW5nIiBFTCBmb3IgZXZhbHVhdGlv biAoanVzdCBsaWtlIGluIHlvdXIgY3VycmVudCB2ZXJzaW9uKSwgInNvcnQuYXNjZW5kaW5nIiBh cyByZXF1ZXN0IHBhcmFtZXRlciBuYW1lLg0KIA0KLS0tDQogDQpXaGF0IGRvIHlvdSB0aGluaz8g SSdtIGtlZW4gb24gYXBwbHlpbmcgdGhlc2UgY2hhbmdlcyBwcm9tcHRseSwgaWYgeW91IGRvbid0 IG1pbmQsIGlmIHBvc3NpYmxlIGFscmVhZHkgdG9tb3Jyb3cuIEJUVywgSSdtIHdyaXRpbmcgdGhp cyBvbiBhIG5vbi1kZXZlbG9wbWVudCBQQyBhdCBob21lLCBzbyBJIGhhdmVuJ3QgYWN0dWFsbHkg cHJvdG90eXBlZCB0aGUgZGVzaWduLCBidXQgSSBleHBlY3QgaXQgdG8gd29yayBuaWNlbHkuIFdl IHNob3VsZCBlbmQgdXAgd2l0aCBzaWduaWZpY2FudGx5IGxlc3MgYW5kIG1vcmUgbWFpbnRhaW5h YmxlIGNvZGUsIEkgaG9wZS4NCiANClJlZ2FyZHMsDQpKdWVyZ2VuDQogDQogDQoNCgktLS0tLVVy c3Byw7xuZ2xpY2hlIE5hY2hyaWNodC0tLS0tIA0KCVZvbjogSlAgUGF3bGFrIFttYWlsdG86anAu cGF3bGFrQHRpc2NhbGkuZnJdIA0KCUdlc2VuZGV0OiBGciAyMy4wNS4yMDAzIDIyOjIwIA0KCUFu OiBTcHJpbmcgRGV2ZWxvcGVycyANCglDYzogDQoJQmV0cmVmZjogW1NwcmluZ2ZyYW1ld29yay1k ZXZlbG9wZXJdIHBhZ2VkIGxpc3RzDQoJDQoJDQoNCg0KCUhpLA0KCQ0KCUV4Y3VzZSBtZSBmcm9t IGRpc3R1cmJpbmcgZnJvbSBmdW5kYW1lbnRhbCBpc3N1ZXMgbGlrZSB0aGUgS2V5QmluZGVyDQoJ cG9zdGVkIGJ5IElzYWJlbGxlIGFuZCB0aGUgYnJva2VuIHRlc3RzIEkndmUganVzdCBwb3N0ZWQu DQoJDQoJQXMgSSB0YWxrZWQgYWJvdXQsIEkgaGF2ZSBhZGRlZCB0aHJlZSBmaWxlczoNCglJbiBz cmM6DQoJICAgLSBjb20uaW50ZXJmYWNlMjEudXRpbC5QYWdlZExpc3RBdXRvSG9sZGVyLmphdmEg KENsYXNzIGRlcml2ZWQgZnJvbQ0KCVBhZ2VkTGlzdEhvbGRlcikNCgkgICAtIGNvbS5pbnRlcmZh Y2UyMS51dGlsLlBhZ2VkTGlzdFNvdXJjZVByb3ZpZGVyLmphdmEgKEludGVyZmFjZSkNCglpbiB0 ZXN0Og0KCSAgIC0gY29tLmludGVyZmFjZTIxLnV0aWwuUGFnZWRMaXN0QXV0b0hvbGRlclRlc3Rz LmphdmEgKENsYXNzKQ0KCQ0KCVRoaXMgYWxsIGZvciBlYXN5IHVzZSBvZiBhIG1vcmUgcG93ZXJm dWxsIHBhZ2VkIExpc3QuDQoJVGhlIGphdmFkb2MgYW5kIGV2ZW50dWFsbHkgdGVzdCBzb3VyY2Ug d2lsbCBub3JtYWxseSBzdWZmaWNlIHRvDQoJdW5kZXJzdGFuZCB0aGUgdXNlLg0KCU5ldmVydGhl bGVzcywgaWYgSSB3aWxsIG5vdCBiZSBpbXBhY3RlZCBieSB0aGUgY3VycmVudCB0ZXN0IGlzc3Vl cywgSQ0KCXdpbGwgdHJ5IHRvIHByb3ZpZGUgYSB0aW55IHNhbXBsZSBhcHBsaWNhdGlvbiBmb3Ig ZGVtb25zdHJhdGluZy4NCgkNCglBZnRlciAwLjggd2lsbCBiZSByZWxlYXNlZCwgSSBjb3VsZCBo YXZlIHNvbWUgaGVscCBmb3IgcmV3aWV2aW5nIHRoZQ0KCWphdmFkb2MgY29tbWVudHMgYXMgbXkg RW5nbGlzaCBpcyB2ZXJ5IGZhciBmcm9tIHBlcmZlY3QuDQoJDQoJUmVnYXJkcywNCglfX19fX19f X19fX19fX19fX19fX19fX19fX19fX18NCglKZWFuLVBpZXJyZSBQYXdsYWsNCglqcC5wYXdsYWtA dGlzY2FsaS5mcg0KCSANCgkNCgkNCgkNCgkNCgktLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQoJVGhpcyBTRi5uZXQgZW1haWwgaXMgc3BvbnNv cmVkIGJ5OiBPYmplY3RTdG9yZS4NCglJZiBmbGF0dGVuaW5nIG91dCBDKysgb3IgSmF2YSBjb2Rl IHRvIG1ha2UgeW91ciBhcHBsaWNhdGlvbiBmaXQgaW4gYQ0KCXJlbGF0aW9uYWwgZGF0YWJhc2Ug aXMgcGFpbmZ1bCwgZG9uJ3QgZG8gaXQhIENoZWNrIG91dCBPYmplY3RTdG9yZS4NCglOb3cgcGFy dCBvZiBQcm9ncmVzcyBTb2Z0d2FyZS4gaHR0cDovL3d3dy5vYmplY3RzdG9yZS5uZXQvc291cmNl Zm9yZ2UNCglfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0K CVNwcmluZ2ZyYW1ld29yay1kZXZlbG9wZXIgbWFpbGluZyBsaXN0DQoJU3ByaW5nZnJhbWV3b3Jr LWRldmVsb3BlckBsaXN0cy5zb3VyY2Vmb3JnZS5uZXQNCglodHRwczovL2xpc3RzLnNvdXJjZWZv cmdlLm5ldC9saXN0cy9saXN0aW5mby9zcHJpbmdmcmFtZXdvcmstZGV2ZWxvcGVyDQoJDQoNCg== |
|
From: Isabelle M. <isa...@me...> - 2003-05-24 16:48:06
|
Hi everyone, I know very little about AOP right now except for the principle, but lying in bath last night it occurred to me that this whole database-dependent key generation problem just might be solved very elegantly using an interceptor. Am I right? Isabelle -- Isabelle Muszynski Software Engineer Zandweellaan 4 2660 Antwerpen Belgium Tel. 32-(0)3-830 18 54 Mobile: 32-(0)485 49 50 89 Email: isa...@me... Website: www.meta-logix.com |
|
From: Isabelle M. <isa...@me...> - 2003-05-24 16:42:27
|
Hi Jean-Pierre,
On second thought, it has to be done your way. Otherwise I'd still have the deferred binding problem. Am implementing it as I write this mail.
Isabelle
On Sat, May 24, 2003 at 12:41:20PM +0200, JP Pawlak wrote:
> Hi Isabelle,
>
>
>
> Why should code such as below not work?
>
> Both for Oracle and MySql, the Incrementer is able to provide a key before the main statement. Letting the developer request for a key and letting him handling this value as it came from the user request will always be possible. There is no always need for sophistication.
>
> If the keys are picked by bunches, we don’t have two database requests.
>
>
>
> Modified test:
>
> /**
>
> * Test an insert that is using sequencing
>
> * @throws Exception if anything goes wrong
>
> */
>
> public void testInsertWithSequence() throws Exception {
>
>
>
> int[] types = new int[] { Types.INTEGER, Types.INTEGER };
>
> Object[] params = new Object[] { null, new Integer(1) };
>
>
>
> JdbcTemplate tpl = new JdbcTemplate(ds);
>
> MySQLMaxValueIncrementer incr = new MySQLMaxValueIncrementer(ds, "insert_test_seq", "seq2");
>
> params[0] = new Integer(incr.nextIntValue());
>
> PreparedStatementCreator psc =
>
> PreparedStatementCreatorFactory.newPreparedStatementCreator("insert into insert_test values(?, ?)", types, params);
>
> numRows = tpl.update(psc);
>
> assertTrue("Row was not inserted", 1 == result.getRowsAffected());
>
> // assertTrue("Key should have been 101", 101 == ((Integer)result.getKey()).intValue());
>
> // Don't need getKey() as we have used incr.nextIntValue()
>
> }
>
>
>
> Best Regards,
>
> Jean-Pierre
>
>
>
> > -----Message d'origine-----
>
> > De : Isabelle Muszynski [mailto:isa...@me...]
>
> > Envoyé : samedi 24 mai 2003 11:18
>
> > À : JP Pawlak
>
> > Cc : spr...@li...
>
> > Objet : Re: RE : [Springframework-developer] SqlUpdate and insert
>
> > functionality
>
> >
>
> > Hi Jean-Pierre,
>
> >
>
> > As I said in the mail I sent a minute ago, the fundamental difference
>
> > between Oracle and MySQL is that in the first you can get the next value
>
> > beforehand, while in the latter you get if afterwards. So I don't think
>
> > your way would work.
>
> >
>
> > Anyway, the thing is badly broken right now.
>
> >
>
> > Isabelle
>
> >
>
> > On Sat, May 24, 2003 at 12:41:36AM +0200, JP Pawlak wrote:
>
> > > Ken,
>
> > >
>
> > > If the javadoc says that a column with auto_increment is to be used,
>
> > > it's clearly a mistake.
>
> > > But that doesn't solve the issue!
>
> > > I used a similar approach with the old framework, but without the Binder
>
> > > technique. I get manually the nextValue in each DAO and set its value
>
> > > like the others parameters in the callback method and it works fine.
>
> > > For now, the Binder mechanism has an open issue (ref last Isabelle's
>
> > > post).
>
> > >
>
> > > Regards,
>
> > > Jean-Pierre
>
> > >
>
> > > -----Message d'origine-----
>
> > > De : spr...@li...
>
> > > [mailto:spr...@li...] De la
>
> > > part de Ken Krebs
>
> > > Envoyé : samedi 24 mai 2003 00:09
>
> > > À : Isabelle Muszynski
>
> > > Cc : spr...@li...
>
> > > Objet : [Springframework-developer] SqlUpdate and insert functionality
>
> > >
>
> > > Isabelle,
>
> > >
>
> > > I don't understand this. I thought auto_increment on the visits id
>
> > > column is what makes it work. The javadoc for MySQLMaxValueIncrementer
>
> > > says that is to be used with an auto_increment column.
>
> > >
>
> > > I tried removing the auto_increment as you suggested and it no longer
>
> > > works.
>
> > >
>
> > > Ken
>
> > >
>
> > > As I said earlier:
>
> > >
>
> > > "The data is written correctly to the DB using the auto-incremented
>
> > > visit_id. The problem is that the getKey() function of the
>
> > > returned InsertRetval returns 0, not the id that was used for the
>
> > > insert. I wanted to use the value to update my cache directly without
>
> > > having to requery the DB for all this pet's visits. I am working around
>
> > > it by doing just that."
>
> > >
>
> > > Isabelle Muszynski wrote:
>
> > >
>
> > > Hi Ken,
>
> > >
>
> > > Looking at the mail you sent me this morning (included below), in table
>
> > > visits, column id is auto-increment, and it shouldn't be. Neither should
>
> > > the sequence column be, which is correct in the code below.
>
> > >
>
> > > The definition of column id should be "int not null primary key"
>
> > >
>
> > > Does this help?
>
> > >
>
> > > Isabelle
>
> > >
>
> > > On Fri, May 23, 2003 at 09:04:01AM -0500, Ken Krebs wrote:
>
> > >
>
> > > Isabelle,
>
> > >
>
> > > My key column isn't auto-incremented, only the actual id column is.
>
> > >
>
> > > My latest code snapshot is attached.
>
> > >
>
> > > Ken
>
> > >
>
> > >
>
> > > Isabelle Muszynski wrote:
>
> > >
>
> > >
>
> > > Hi Ken,
>
> > >
>
> > > Your key column should NOT be auto-increment.
>
> > >
>
> > > If that doesn't solve the problem, let me know, and pls attach the code
>
> > > so
>
> > > I don't have top type it over. Will look at it tonight or tomorrow. I'll
>
> > >
>
> > > also look into the strange log output, probably a stupid booboo.
>
> > >
>
> > > Isabelle
>
> > >
>
> > > On Thu, May 22, 2003 at 11:25:08PM -0500, Ken Krebs wrote:
>
> > >
>
> > >
>
> > >
>
> > > Hi Isabelle,
>
> > >
>
> > > I have a problem using the following petclinic class that inserts a new
>
> > > visit into the DB :
>
> > >
>
> > > class NewVisit extends SqlUpdate {
>
> > >
>
> > > public NewVisit(DataSource ds) {
>
> > > super(ds, "INSERT INTO visits VALUES(?,?,?,?)");
>
> > > declareParameter(new SqlParameter(Types.INTEGER));
>
> > > declareParameter(new SqlParameter(Types.INTEGER));
>
> > > declareParameter(new SqlParameter(Types.DATE));
>
> > > declareParameter(new SqlParameter(Types.VARCHAR));
>
> > > compile();
>
> > > }
>
> > >
>
> > > public int insert(Visit visit) {
>
> > > KeyBinder keybinder = new KeyBinder() {
>
> > > public void bind(PreparedStatement ps, Object obj)
>
> > > throws SQLException {
>
> > > ps.setObject(1, obj);
>
> > > }
>
> > > };
>
> > >
>
> > > MySQLMaxValueIncrementer incr = new
>
> > > MySQLMaxValueIncrementer(getDataSource(), "visits_seq", "seq", 1);
>
> > >
>
> > > logger.info("Visit petId = " + visit.getPetId());
>
> > >
>
> > > Object[] objs = new Object[] {
>
> > > null,
>
> > > new Integer(visit.getPetId()),
>
> > > visit.getVisitDate(),
>
> > > visit.getDescription()
>
> > > };
>
> > >
>
> > > JdbcTemplate.InsertRetval retVal = update(objs, keybinder,
>
> > > incr, Integer.class);
>
> > > visit.setId(((Integer) retVal.getKey()).intValue());
>
> > >
>
> > > logger.info("Visit id = " + visit.getId() + " petId = " +
>
> > > visit.getPetId());
>
> > >
>
> > > return retVal.getRowsAffected();
>
> > > }
>
> > >
>
> > > }
>
> > >
>
> > > My table definitions for visits and its sequencer are :
>
> > >
>
> > > CREATE TABLE visits (
>
> > > id INT(4) UNSIGNED NOT NULL AUTO_INCREMENT,
>
> > > pet_id INT(4) UNSIGNED NOT NULL REFERENCES pets(id),
>
> > > visit_date DATE,
>
> > > description VARCHAR(255),
>
> > > PRIMARY KEY(id),
>
> > > INDEX(pet_id)
>
> > > );
>
> > > INSERT INTO visits VALUES (1, 7, '1996-03-04', 'rabies shot');
>
> > > INSERT INTO visits VALUES (NULL, 8, '1996-03-04', 'rabies shot');
>
> > > INSERT INTO visits VALUES (NULL, 8, '1996-06-04', 'neutered');
>
> > > INSERT INTO visits VALUES (NULL, 7, '1996-09-04', 'spayed');
>
> > >
>
> > > CREATE TABLE visits_seq (
>
> > > seq INT(4) UNSIGNED NOT NULL
>
> > > );
>
> > > INSERT INTO visits_seq VALUES (5);
>
> > >
>
> > >
>
> > > The data is written correctly to the DB using the auto-incremented
>
> > > visit_id. The problem is that the getKey() function of the
>
> > > returned InsertRetval returns 0, not the id that was used for the
>
> > > insert. I wanted to use the value to update my cache directly without
>
> > > having to requery the DB for all this pet's visits. I am working around
>
> > > it by doing just that.
>
> > >
>
> > >
>
> > > I include below a relevant snippet from the INFO log:
>
> > >
>
> > > 2003-05-22 22:53:37,966 INFO [petclinic.support.ClinicImpl$NewVisit] -
>
> > > <Compiled OK>
>
> > > 2003-05-22 22:53:37,996 INFO [petclinic.support.ClinicImpl$NewVisit] -
>
> > > <Visit petId = 7>
>
> > > 2003-05-22 22:53:38,006 INFO [com.interface21.jdbc.object.SqlUpdate] -
>
> > > <Compiled OK>
>
> > > 2003-05-22 22:53:38,016 INFO [com.interface21.jdbc.core.JdbcTemplate] -
>
> > > <JDBCTemplate: update affected 1 rows>
>
> > > 2003-05-22 22:53:38,016 INFO [com.interface21.jdbc.object.SqlUpdate] -
>
> > > <1 rows affected by SQL update [update visits_seq set seq =
>
> > > last_insert_id(seq + 1)]>
>
> > > 2003-05-22 22:53:38,026 INFO [com.interface21.jdbc.object.SqlFunction] -
>
> > >
>
> > > <Compiled OK>
>
> > > 2003-05-22 22:53:38,036 INFO [com.interface21.jdbc.core.JdbcTemplate] -
>
> > > <Executing SQL query using PreparedStatement:
>
> > > [PreparedStatementCreatorFactory.PreparedStatementCreatorImpl:
>
> > > sql={select last_insert_id()}: params={}]>
>
> > > 2003-05-22 22:53:38,036 INFO [com.interface21.jdbc.core.JdbcTemplate] -
>
> > > <JDBCTemplate: update affected
>
> > > com.interface21.jdbc.core.JdbcTemplate$InsertRetval@1ebe3f0 rows>
>
> > > 2003-05-22 22:53:38,036 INFO [petclinic.support.ClinicImpl$NewVisit] -
>
> > > <Visit id = 0 petId = 7>
>
> > >
>
> > > Note that the last line shows the visit_id == 0.
>
> > > Also note the odd output of the 2nd last line where instead of
>
> > > outputting the no. of rows affected it's printing a toString() of the
>
> > > InsertRetval !!!???
>
> > >
>
> > >
>
> > > Am I doing something wrong here ?
>
> > >
>
> > >
>
> > > Regards,
>
> > >
>
> > > Ken
>
> > >
>
> >
>
> > --
>
> > Isabelle Muszynski
>
> > Software Engineer
>
> > Zandweellaan 4
>
> > 2660 Antwerpen
>
> > Belgium
>
> > Tel. 32-(0)3-830 18 54
>
> > Mobile: 32-(0)485 49 50 89
>
> > Email: isa...@me...
>
> > Website: www.meta-logix.com
>
--
Isabelle Muszynski
Software Engineer
Zandweellaan 4
2660 Antwerpen
Belgium
Tel. 32-(0)3-830 18 54
Mobile: 32-(0)485 49 50 89
Email: isa...@me...
Website: www.meta-logix.com
|
|
From: Isabelle M. <isa...@me...> - 2003-05-24 16:30:21
|
Hi Jean-Pierre,
I was away all afternoon and did some more thinking about the problem, and came to the same conclusion as you apparently did : the sequence table should stay, but the KeyBinder interface needs to go away. Instead of the KeyBinder argument, the caller needs to pass the index of the key column so that JdbcTemplate can do the binding.
The difference with your sample is that the caller doesn't do the binding, JdbcTemplate does.
Are we on the same wavelength?
Best regards,
Isabelle
On Sat, May 24, 2003 at 12:41:20PM +0200, JP Pawlak wrote:
> Hi Isabelle,
>
>
>
> Why should code such as below not work?
>
> Both for Oracle and MySql, the Incrementer is able to provide a key before the main statement. Letting the developer request for a key and letting him handling this value as it came from the user request will always be possible. There is no always need for sophistication.
>
> If the keys are picked by bunches, we don’t have two database requests.
>
>
>
> Modified test:
>
> /**
>
> * Test an insert that is using sequencing
>
> * @throws Exception if anything goes wrong
>
> */
>
> public void testInsertWithSequence() throws Exception {
>
>
>
> int[] types = new int[] { Types.INTEGER, Types.INTEGER };
>
> Object[] params = new Object[] { null, new Integer(1) };
>
>
>
> JdbcTemplate tpl = new JdbcTemplate(ds);
>
> MySQLMaxValueIncrementer incr = new MySQLMaxValueIncrementer(ds, "insert_test_seq", "seq2");
>
> params[0] = new Integer(incr.nextIntValue());
>
> PreparedStatementCreator psc =
>
> PreparedStatementCreatorFactory.newPreparedStatementCreator("insert into insert_test values(?, ?)", types, params);
>
> numRows = tpl.update(psc);
>
> assertTrue("Row was not inserted", 1 == result.getRowsAffected());
>
> // assertTrue("Key should have been 101", 101 == ((Integer)result.getKey()).intValue());
>
> // Don't need getKey() as we have used incr.nextIntValue()
>
> }
>
>
>
> Best Regards,
>
> Jean-Pierre
>
>
>
> > -----Message d'origine-----
>
> > De : Isabelle Muszynski [mailto:isa...@me...]
>
> > Envoyé : samedi 24 mai 2003 11:18
>
> > À : JP Pawlak
>
> > Cc : spr...@li...
>
> > Objet : Re: RE : [Springframework-developer] SqlUpdate and insert
>
> > functionality
>
> >
>
> > Hi Jean-Pierre,
>
> >
>
> > As I said in the mail I sent a minute ago, the fundamental difference
>
> > between Oracle and MySQL is that in the first you can get the next value
>
> > beforehand, while in the latter you get if afterwards. So I don't think
>
> > your way would work.
>
> >
>
> > Anyway, the thing is badly broken right now.
>
> >
>
> > Isabelle
>
> >
>
> > On Sat, May 24, 2003 at 12:41:36AM +0200, JP Pawlak wrote:
>
> > > Ken,
>
> > >
>
> > > If the javadoc says that a column with auto_increment is to be used,
>
> > > it's clearly a mistake.
>
> > > But that doesn't solve the issue!
>
> > > I used a similar approach with the old framework, but without the Binder
>
> > > technique. I get manually the nextValue in each DAO and set its value
>
> > > like the others parameters in the callback method and it works fine.
>
> > > For now, the Binder mechanism has an open issue (ref last Isabelle's
>
> > > post).
>
> > >
>
> > > Regards,
>
> > > Jean-Pierre
>
> > >
>
> > > -----Message d'origine-----
>
> > > De : spr...@li...
>
> > > [mailto:spr...@li...] De la
>
> > > part de Ken Krebs
>
> > > Envoyé : samedi 24 mai 2003 00:09
>
> > > À : Isabelle Muszynski
>
> > > Cc : spr...@li...
>
> > > Objet : [Springframework-developer] SqlUpdate and insert functionality
>
> > >
>
> > > Isabelle,
>
> > >
>
> > > I don't understand this. I thought auto_increment on the visits id
>
> > > column is what makes it work. The javadoc for MySQLMaxValueIncrementer
>
> > > says that is to be used with an auto_increment column.
>
> > >
>
> > > I tried removing the auto_increment as you suggested and it no longer
>
> > > works.
>
> > >
>
> > > Ken
>
> > >
>
> > > As I said earlier:
>
> > >
>
> > > "The data is written correctly to the DB using the auto-incremented
>
> > > visit_id. The problem is that the getKey() function of the
>
> > > returned InsertRetval returns 0, not the id that was used for the
>
> > > insert. I wanted to use the value to update my cache directly without
>
> > > having to requery the DB for all this pet's visits. I am working around
>
> > > it by doing just that."
>
> > >
>
> > > Isabelle Muszynski wrote:
>
> > >
>
> > > Hi Ken,
>
> > >
>
> > > Looking at the mail you sent me this morning (included below), in table
>
> > > visits, column id is auto-increment, and it shouldn't be. Neither should
>
> > > the sequence column be, which is correct in the code below.
>
> > >
>
> > > The definition of column id should be "int not null primary key"
>
> > >
>
> > > Does this help?
>
> > >
>
> > > Isabelle
>
> > >
>
> > > On Fri, May 23, 2003 at 09:04:01AM -0500, Ken Krebs wrote:
>
> > >
>
> > > Isabelle,
>
> > >
>
> > > My key column isn't auto-incremented, only the actual id column is.
>
> > >
>
> > > My latest code snapshot is attached.
>
> > >
>
> > > Ken
>
> > >
>
> > >
>
> > > Isabelle Muszynski wrote:
>
> > >
>
> > >
>
> > > Hi Ken,
>
> > >
>
> > > Your key column should NOT be auto-increment.
>
> > >
>
> > > If that doesn't solve the problem, let me know, and pls attach the code
>
> > > so
>
> > > I don't have top type it over. Will look at it tonight or tomorrow. I'll
>
> > >
>
> > > also look into the strange log output, probably a stupid booboo.
>
> > >
>
> > > Isabelle
>
> > >
>
> > > On Thu, May 22, 2003 at 11:25:08PM -0500, Ken Krebs wrote:
>
> > >
>
> > >
>
> > >
>
> > > Hi Isabelle,
>
> > >
>
> > > I have a problem using the following petclinic class that inserts a new
>
> > > visit into the DB :
>
> > >
>
> > > class NewVisit extends SqlUpdate {
>
> > >
>
> > > public NewVisit(DataSource ds) {
>
> > > super(ds, "INSERT INTO visits VALUES(?,?,?,?)");
>
> > > declareParameter(new SqlParameter(Types.INTEGER));
>
> > > declareParameter(new SqlParameter(Types.INTEGER));
>
> > > declareParameter(new SqlParameter(Types.DATE));
>
> > > declareParameter(new SqlParameter(Types.VARCHAR));
>
> > > compile();
>
> > > }
>
> > >
>
> > > public int insert(Visit visit) {
>
> > > KeyBinder keybinder = new KeyBinder() {
>
> > > public void bind(PreparedStatement ps, Object obj)
>
> > > throws SQLException {
>
> > > ps.setObject(1, obj);
>
> > > }
>
> > > };
>
> > >
>
> > > MySQLMaxValueIncrementer incr = new
>
> > > MySQLMaxValueIncrementer(getDataSource(), "visits_seq", "seq", 1);
>
> > >
>
> > > logger.info("Visit petId = " + visit.getPetId());
>
> > >
>
> > > Object[] objs = new Object[] {
>
> > > null,
>
> > > new Integer(visit.getPetId()),
>
> > > visit.getVisitDate(),
>
> > > visit.getDescription()
>
> > > };
>
> > >
>
> > > JdbcTemplate.InsertRetval retVal = update(objs, keybinder,
>
> > > incr, Integer.class);
>
> > > visit.setId(((Integer) retVal.getKey()).intValue());
>
> > >
>
> > > logger.info("Visit id = " + visit.getId() + " petId = " +
>
> > > visit.getPetId());
>
> > >
>
> > > return retVal.getRowsAffected();
>
> > > }
>
> > >
>
> > > }
>
> > >
>
> > > My table definitions for visits and its sequencer are :
>
> > >
>
> > > CREATE TABLE visits (
>
> > > id INT(4) UNSIGNED NOT NULL AUTO_INCREMENT,
>
> > > pet_id INT(4) UNSIGNED NOT NULL REFERENCES pets(id),
>
> > > visit_date DATE,
>
> > > description VARCHAR(255),
>
> > > PRIMARY KEY(id),
>
> > > INDEX(pet_id)
>
> > > );
>
> > > INSERT INTO visits VALUES (1, 7, '1996-03-04', 'rabies shot');
>
> > > INSERT INTO visits VALUES (NULL, 8, '1996-03-04', 'rabies shot');
>
> > > INSERT INTO visits VALUES (NULL, 8, '1996-06-04', 'neutered');
>
> > > INSERT INTO visits VALUES (NULL, 7, '1996-09-04', 'spayed');
>
> > >
>
> > > CREATE TABLE visits_seq (
>
> > > seq INT(4) UNSIGNED NOT NULL
>
> > > );
>
> > > INSERT INTO visits_seq VALUES (5);
>
> > >
>
> > >
>
> > > The data is written correctly to the DB using the auto-incremented
>
> > > visit_id. The problem is that the getKey() function of the
>
> > > returned InsertRetval returns 0, not the id that was used for the
>
> > > insert. I wanted to use the value to update my cache directly without
>
> > > having to requery the DB for all this pet's visits. I am working around
>
> > > it by doing just that.
>
> > >
>
> > >
>
> > > I include below a relevant snippet from the INFO log:
>
> > >
>
> > > 2003-05-22 22:53:37,966 INFO [petclinic.support.ClinicImpl$NewVisit] -
>
> > > <Compiled OK>
>
> > > 2003-05-22 22:53:37,996 INFO [petclinic.support.ClinicImpl$NewVisit] -
>
> > > <Visit petId = 7>
>
> > > 2003-05-22 22:53:38,006 INFO [com.interface21.jdbc.object.SqlUpdate] -
>
> > > <Compiled OK>
>
> > > 2003-05-22 22:53:38,016 INFO [com.interface21.jdbc.core.JdbcTemplate] -
>
> > > <JDBCTemplate: update affected 1 rows>
>
> > > 2003-05-22 22:53:38,016 INFO [com.interface21.jdbc.object.SqlUpdate] -
>
> > > <1 rows affected by SQL update [update visits_seq set seq =
>
> > > last_insert_id(seq + 1)]>
>
> > > 2003-05-22 22:53:38,026 INFO [com.interface21.jdbc.object.SqlFunction] -
>
> > >
>
> > > <Compiled OK>
>
> > > 2003-05-22 22:53:38,036 INFO [com.interface21.jdbc.core.JdbcTemplate] -
>
> > > <Executing SQL query using PreparedStatement:
>
> > > [PreparedStatementCreatorFactory.PreparedStatementCreatorImpl:
>
> > > sql={select last_insert_id()}: params={}]>
>
> > > 2003-05-22 22:53:38,036 INFO [com.interface21.jdbc.core.JdbcTemplate] -
>
> > > <JDBCTemplate: update affected
>
> > > com.interface21.jdbc.core.JdbcTemplate$InsertRetval@1ebe3f0 rows>
>
> > > 2003-05-22 22:53:38,036 INFO [petclinic.support.ClinicImpl$NewVisit] -
>
> > > <Visit id = 0 petId = 7>
>
> > >
>
> > > Note that the last line shows the visit_id == 0.
>
> > > Also note the odd output of the 2nd last line where instead of
>
> > > outputting the no. of rows affected it's printing a toString() of the
>
> > > InsertRetval !!!???
>
> > >
>
> > >
>
> > > Am I doing something wrong here ?
>
> > >
>
> > >
>
> > > Regards,
>
> > >
>
> > > Ken
>
> > >
>
> >
>
> > --
>
> > Isabelle Muszynski
>
> > Software Engineer
>
> > Zandweellaan 4
>
> > 2660 Antwerpen
>
> > Belgium
>
> > Tel. 32-(0)3-830 18 54
>
> > Mobile: 32-(0)485 49 50 89
>
> > Email: isa...@me...
>
> > Website: www.meta-logix.com
>
--
Isabelle Muszynski
Software Engineer
Zandweellaan 4
2660 Antwerpen
Belgium
Tel. 32-(0)3-830 18 54
Mobile: 32-(0)485 49 50 89
Email: isa...@me...
Website: www.meta-logix.com
|
|
From: JP P. <jp....@ti...> - 2003-05-24 14:28:00
|
Hi, A first version of paged list demo application is available. For now:=20 - no ant script is available - the localization is not implemented They are very minor works, but now Mother's Day. Simply rename the zip file as war. The src under WEB-INF contains the java-part sources. Download: http://www.achappro.com/pagedlist.zip Regards, Jean-Pierre ___________________________________=A0 Jean-Pierre Pawlak jp....@ti... =A0 |
|
From: JP P. <jp....@ti...> - 2003-05-24 14:02:53
|
Hi, As my first message seems not pass on the list, I resend it. A first version of paged list demo application is available. For now:=20 - no ant script is available - the localization is not implemented - I will add links to the detail page from the list. - In conjunction with the excel view, I will add the possibility of receiving an excel file containing the selection. They are very minor works, but now Mother's Day. Simply rename the zip file as war. The src under WEB-INF contains the java-part sources. Download: http://www.achappro.com/pagedlist.zip It can also be tested at http://www.achappro.com/pagedlist/ Regards, Jean-Pierre ___________________________________=A0 Jean-Pierre Pawlak jp....@ti... =A0 |
|
From: JP P. <jp....@ti...> - 2003-05-24 11:12:35
|
Hi Isabelle,
Why should code such as below not work?=20
Both for Oracle and MySql, the Incrementer is able to provide a key =
before the main statement. Letting the developer request for a key and =
letting him handling this value as it came from the user request will =
always be possible. There is no always need for sophistication.
If the keys are picked by bunches, we don=E2=80=99t have two database =
requests.=20
Just we don't use the Oracle's common approach to give a null and =
setting a trigger providing the value.=20
Modified test:
/**
* Test an insert that is using sequencing
* @throws Exception if anything goes wrong
*/
public void testInsertWithSequence() throws Exception {
int[] types =3D new int[] { Types.INTEGER, Types.INTEGER };
Object[] params =3D new Object[] { null, new Integer(1) };
JdbcTemplate tpl =3D new JdbcTemplate(ds);
MySQLMaxValueIncrementer incr =3D new MySQLMaxValueIncrementer(ds, =
"insert_test_seq", "seq2");
params[0] =3D new Integer(incr.nextIntValue());
PreparedStatementCreator psc =3D=20
PreparedStatementCreatorFactory.newPreparedStatementCreator("insert =
into insert_test values(?, ?)", types, params);
numRows =3D tpl.update(psc);
assertTrue("Row was not inserted", 1 =3D=3D result.getRowsAffected());
// assertTrue("Key should have been 101", 101 =3D=3D =
((Integer)result.getKey()).intValue());
// Don't need getKey() as we have used incr.nextIntValue()
}
Best Regards,
Jean-Pierre
> -----Message d'origine-----
> De : Isabelle Muszynski [mailto:isa...@me...]
> Envoy=C3=A9 : samedi 24 mai 2003 11:18
> =C3=80 : JP Pawlak
> Cc : spr...@li...
> Objet : Re: RE : [Springframework-developer] SqlUpdate and insert
> functionality
>=20
> Hi Jean-Pierre,
>=20
> As I said in the mail I sent a minute ago, the fundamental difference
> between Oracle and MySQL is that in the first you can get the next =
value
> beforehand, while in the latter you get if afterwards. So I don't =
think
> your way would work.
>=20
> Anyway, the thing is badly broken right now.
>=20
> Isabelle
>=20
> On Sat, May 24, 2003 at 12:41:36AM +0200, JP Pawlak wrote:
> > Ken,
> >
> > If the javadoc says that a column with auto_increment is to be used,
> > it's clearly a mistake.
> > But that doesn't solve the issue!
> > I used a similar approach with the old framework, but without the =
Binder
> > technique. I get manually the nextValue in each DAO and set its =
value
> > like the others parameters in the callback method and it works fine.
> > For now, the Binder mechanism has an open issue (ref last Isabelle's
> > post).
> >
> > Regards,
> > Jean-Pierre
> >
> > -----Message d'origine-----
> > De=C3=82 : spr...@li...
> > [mailto:spr...@li...] De la
> > part de Ken Krebs
> > Envoy=C3=83=C2=A9=C3=82 : samedi 24 mai 2003 00:09
> > =C3=83=E2=82=AC=C3=82 : Isabelle Muszynski
> > Cc=C3=82 : spr...@li...
> > Objet=C3=82 : [Springframework-developer] SqlUpdate and insert =
functionality
> >
> > Isabelle,
> >
> > I don't understand this. I thought auto_increment on the visits id
> > column is what makes it work. The javadoc for =
MySQLMaxValueIncrementer
> > says that is to be used with an auto_increment column.
> >
> > I tried removing the auto_increment as you suggested and it no =
longer
> > works.
> >
> > Ken
> >
> > As I said earlier:
> >
> > "The data is written correctly to the DB using the auto-incremented
> > visit_id. The problem is that the getKey() function of the
> > returned InsertRetval returns 0, not the id that was used for the
> > insert. I wanted to use the value to update my cache directly =
without
> > having to requery the DB for all this pet's visits. I am working =
around
> > it by doing just that."
> >
> > Isabelle Muszynski wrote:
> >
> > Hi Ken,
> >
> > Looking at the mail you sent me this morning (included below), in =
table
> > visits, column id is auto-increment, and it shouldn't be. Neither =
should
> > the sequence column be, which is correct in the code below.
> >
> > The definition of column id should be "int not null primary key"
> >
> > Does this help?
> >
> > Isabelle
> >
> > On Fri, May 23, 2003 at 09:04:01AM -0500, Ken Krebs wrote:
> >
> > Isabelle,
> >
> > My key column isn't auto-incremented, only the actual id column is.
> >
> > My latest code snapshot is attached.
> >
|
|
From: Isabelle M. <isa...@me...> - 2003-05-24 09:18:37
|
Hi Jean-Pierre,
As I said in the mail I sent a minute ago, the fundamental difference between Oracle and MySQL is that in the first you can get the next value beforehand, while in the latter you get if afterwards. So I don't think your way would work.
Anyway, the thing is badly broken right now.
Isabelle
On Sat, May 24, 2003 at 12:41:36AM +0200, JP Pawlak wrote:
> Ken,
>
> If the javadoc says that a column with auto_increment is to be used,
> it's clearly a mistake.
> But that doesn't solve the issue!
> I used a similar approach with the old framework, but without the Binder
> technique. I get manually the nextValue in each DAO and set its value
> like the others parameters in the callback method and it works fine.
> For now, the Binder mechanism has an open issue (ref last Isabelle's
> post).
>
> Regards,
> Jean-Pierre
>
> -----Message d'origine-----
> De : spr...@li...
> [mailto:spr...@li...] De la
> part de Ken Krebs
> Envoyé : samedi 24 mai 2003 00:09
> ÃÂ : Isabelle Muszynski
> Cc : spr...@li...
> Objet : [Springframework-developer] SqlUpdate and insert functionality
>
> Isabelle,
>
> I don't understand this. I thought auto_increment on the visits id
> column is what makes it work. The javadoc for MySQLMaxValueIncrementer
> says that is to be used with an auto_increment column.
>
> I tried removing the auto_increment as you suggested and it no longer
> works.
>
> Ken
>
> As I said earlier:
>
> "The data is written correctly to the DB using the auto-incremented
> visit_id. The problem is that the getKey() function of the
> returned InsertRetval returns 0, not the id that was used for the
> insert. I wanted to use the value to update my cache directly without
> having to requery the DB for all this pet's visits. I am working around
> it by doing just that."
>
> Isabelle Muszynski wrote:
>
> Hi Ken,
>
> Looking at the mail you sent me this morning (included below), in table
> visits, column id is auto-increment, and it shouldn't be. Neither should
> the sequence column be, which is correct in the code below.
>
> The definition of column id should be "int not null primary key"
>
> Does this help?
>
> Isabelle
>
> On Fri, May 23, 2003 at 09:04:01AM -0500, Ken Krebs wrote:
>
> Isabelle,
>
> My key column isn't auto-incremented, only the actual id column is.
>
> My latest code snapshot is attached.
>
> Ken
>
>
> Isabelle Muszynski wrote:
>
>
> Hi Ken,
>
> Your key column should NOT be auto-increment.
>
> If that doesn't solve the problem, let me know, and pls attach the code
> so
> I don't have top type it over. Will look at it tonight or tomorrow. I'll
>
> also look into the strange log output, probably a stupid booboo.
>
> Isabelle
>
> On Thu, May 22, 2003 at 11:25:08PM -0500, Ken Krebs wrote:
>
>
>
> Hi Isabelle,
>
> I have a problem using the following petclinic class that inserts a new
> visit into the DB :
>
> class NewVisit extends SqlUpdate {
>
> public NewVisit(DataSource ds) {
> super(ds, "INSERT INTO visits VALUES(?,?,?,?)");
> declareParameter(new SqlParameter(Types.INTEGER));
> declareParameter(new SqlParameter(Types.INTEGER));
> declareParameter(new SqlParameter(Types.DATE));
> declareParameter(new SqlParameter(Types.VARCHAR));
> compile();
> }
>
> public int insert(Visit visit) {
> KeyBinder keybinder = new KeyBinder() {
> public void bind(PreparedStatement ps, Object obj)
> throws SQLException {
> ps.setObject(1, obj);
> }
> };
>
> MySQLMaxValueIncrementer incr = new
> MySQLMaxValueIncrementer(getDataSource(), "visits_seq", "seq", 1);
>
> logger.info("Visit petId = " + visit.getPetId());
>
> Object[] objs = new Object[] {
> null,
> new Integer(visit.getPetId()),
> visit.getVisitDate(),
> visit.getDescription()
> };
>
> JdbcTemplate.InsertRetval retVal = update(objs, keybinder,
> incr, Integer.class);
> visit.setId(((Integer) retVal.getKey()).intValue());
>
> logger.info("Visit id = " + visit.getId() + " petId = " +
> visit.getPetId());
>
> return retVal.getRowsAffected();
> }
>
> }
>
> My table definitions for visits and its sequencer are :
>
> CREATE TABLE visits (
> id INT(4) UNSIGNED NOT NULL AUTO_INCREMENT,
> pet_id INT(4) UNSIGNED NOT NULL REFERENCES pets(id),
> visit_date DATE,
> description VARCHAR(255),
> PRIMARY KEY(id),
> INDEX(pet_id)
> );
> INSERT INTO visits VALUES (1, 7, '1996-03-04', 'rabies shot');
> INSERT INTO visits VALUES (NULL, 8, '1996-03-04', 'rabies shot');
> INSERT INTO visits VALUES (NULL, 8, '1996-06-04', 'neutered');
> INSERT INTO visits VALUES (NULL, 7, '1996-09-04', 'spayed');
>
> CREATE TABLE visits_seq (
> seq INT(4) UNSIGNED NOT NULL
> );
> INSERT INTO visits_seq VALUES (5);
>
>
> The data is written correctly to the DB using the auto-incremented
> visit_id. The problem is that the getKey() function of the
> returned InsertRetval returns 0, not the id that was used for the
> insert. I wanted to use the value to update my cache directly without
> having to requery the DB for all this pet's visits. I am working around
> it by doing just that.
>
>
> I include below a relevant snippet from the INFO log:
>
> 2003-05-22 22:53:37,966 INFO [petclinic.support.ClinicImpl$NewVisit] -
> <Compiled OK>
> 2003-05-22 22:53:37,996 INFO [petclinic.support.ClinicImpl$NewVisit] -
> <Visit petId = 7>
> 2003-05-22 22:53:38,006 INFO [com.interface21.jdbc.object.SqlUpdate] -
> <Compiled OK>
> 2003-05-22 22:53:38,016 INFO [com.interface21.jdbc.core.JdbcTemplate] -
> <JDBCTemplate: update affected 1 rows>
> 2003-05-22 22:53:38,016 INFO [com.interface21.jdbc.object.SqlUpdate] -
> <1 rows affected by SQL update [update visits_seq set seq =
> last_insert_id(seq + 1)]>
> 2003-05-22 22:53:38,026 INFO [com.interface21.jdbc.object.SqlFunction] -
>
> <Compiled OK>
> 2003-05-22 22:53:38,036 INFO [com.interface21.jdbc.core.JdbcTemplate] -
> <Executing SQL query using PreparedStatement:
> [PreparedStatementCreatorFactory.PreparedStatementCreatorImpl:
> sql={select last_insert_id()}: params={}]>
> 2003-05-22 22:53:38,036 INFO [com.interface21.jdbc.core.JdbcTemplate] -
> <JDBCTemplate: update affected
> com.interface21.jdbc.core.JdbcTemplate$InsertRetval@1ebe3f0 rows>
> 2003-05-22 22:53:38,036 INFO [petclinic.support.ClinicImpl$NewVisit] -
> <Visit id = 0 petId = 7>
>
> Note that the last line shows the visit_id == 0.
> Also note the odd output of the 2nd last line where instead of
> outputting the no. of rows affected it's printing a toString() of the
> InsertRetval !!!???
>
>
> Am I doing something wrong here ?
>
>
> Regards,
>
> Ken
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
--
Isabelle Muszynski
Software Engineer
Zandweellaan 4
2660 Antwerpen
Belgium
Tel. 32-(0)3-830 18 54
Mobile: 32-(0)485 49 50 89
Email: isa...@me...
Website: www.meta-logix.com
|
|
From: Isabelle M. <isa...@me...> - 2003-05-24 09:16:04
|
Hi everyone,
The javadoc comment is a major booboo on my part. The column should not be auto-increment, because the sequence table does that.
HOWEVER: I have been rethinking the whole approach, and I think I need to get rid of the KeyBinder and use the auto-increment feature instead. The user would then pass NULL, the column IS auto-increment, and there are no sequence tables).
I'm giving this top priority, we cannot release with a bug. I'm hoping to get it done by sunday night.
Reading in the MySQL Cookbook, there is a way to retrieve the last inserted id in one round-trip using MySQL-specific API methods. The alternative is 2 use 2 statements : first the insert with a with a NULL, then call last-insert-id(). The last inserted id is kept on a per-connection basis, so I think everything should be OK when used in a container that pools connections.
It seems to me that, when inserting with a sequence, we have to have something like
preprocess()
update()
postprocess()
return id
Depending on the database, either or both of preprocess and postprocess may be empty.
Comments are welcome.
Isabelle
On Fri, May 23, 2003 at 05:09:28PM -0500, Ken Krebs wrote:
> Isabelle,
>
> I don't understand this. I thought auto_increment on the visits id
> column is what makes it work. The javadoc for MySQLMaxValueIncrementer
> says that is to be used with an auto_increment column.
>
> I tried removing the auto_increment as you suggested and it no longer works.
>
> Ken
>
> As I said earlier:
>
> "The data is written correctly to the DB using the auto-incremented
> visit_id. The problem is that the getKey() function of the
> returned InsertRetval returns 0, not the id that was used for the
> insert. I wanted to use the value to update my cache directly without
> having to requery the DB for all this pet's visits. I am working around
> it by doing just that."
>
>
> Isabelle Muszynski wrote:
>
> >Hi Ken,
> >
> >Looking at the mail you sent me this morning (included below), in table
> >visits, column id is auto-increment, and it shouldn't be. Neither should
> >the sequence column be, which is correct in the code below.
> >
> >The definition of column id should be "int not null primary key"
> >
> >Does this help?
> >
> >Isabelle
> >
> >On Fri, May 23, 2003 at 09:04:01AM -0500, Ken Krebs wrote:
> >
> >
> >>Isabelle,
> >>
> >>My key column isn't auto-incremented, only the actual id column is.
> >>
> >>My latest code snapshot is attached.
> >>
> >>Ken
> >>
> >>
> >>Isabelle Muszynski wrote:
> >>
> >>
> >>
> >>>Hi Ken,
> >>>
> >>>Your key column should NOT be auto-increment.
> >>>
> >>>If that doesn't solve the problem, let me know, and pls attach the code
> >>>so I don't have top type it over. Will look at it tonight or tomorrow.
> >>>I'll also look into the strange log output, probably a stupid booboo.
> >>>
> >>>Isabelle
> >>>
> >>>On Thu, May 22, 2003 at 11:25:08PM -0500, Ken Krebs wrote:
> >>>
> >>>
> >>>
> >>>
> >>>>Hi Isabelle,
> >>>>
> >>>>I have a problem using the following petclinic class that inserts a new
> >>>>visit into the DB :
> >>>>
> >>>>class NewVisit extends SqlUpdate {
> >>>>
> >>>> public NewVisit(DataSource ds) {
> >>>> super(ds, "INSERT INTO visits VALUES(?,?,?,?)");
> >>>> declareParameter(new SqlParameter(Types.INTEGER));
> >>>> declareParameter(new SqlParameter(Types.INTEGER));
> >>>> declareParameter(new SqlParameter(Types.DATE));
> >>>> declareParameter(new SqlParameter(Types.VARCHAR));
> >>>> compile();
> >>>> }
> >>>>
> >>>> public int insert(Visit visit) {
> >>>> KeyBinder keybinder = new KeyBinder() {
> >>>> public void bind(PreparedStatement ps, Object obj)
> >>>>throws SQLException {
> >>>> ps.setObject(1, obj);
> >>>> }
> >>>> };
> >>>>
> >>>> MySQLMaxValueIncrementer incr = new
> >>>>MySQLMaxValueIncrementer(getDataSource(), "visits_seq", "seq", 1);
> >>>>
> >>>> logger.info("Visit petId = " + visit.getPetId());
> >>>>
> >>>> Object[] objs = new Object[] {
> >>>> null,
> >>>> new Integer(visit.getPetId()),
> >>>> visit.getVisitDate(),
> >>>> visit.getDescription()
> >>>> };
> >>>>
> >>>> JdbcTemplate.InsertRetval retVal = update(objs, keybinder,
> >>>>incr, Integer.class);
> >>>> visit.setId(((Integer) retVal.getKey()).intValue());
> >>>>
> >>>> logger.info("Visit id = " + visit.getId() + " petId = " +
> >>>>visit.getPetId());
> >>>>
> >>>> return retVal.getRowsAffected();
> >>>> }
> >>>>
> >>>>}
> >>>>
> >>>>My table definitions for visits and its sequencer are :
> >>>>
> >>>>CREATE TABLE visits (
> >>>>id INT(4) UNSIGNED NOT NULL AUTO_INCREMENT,
> >>>>pet_id INT(4) UNSIGNED NOT NULL REFERENCES pets(id),
> >>>>visit_date DATE,
> >>>>description VARCHAR(255),
> >>>>PRIMARY KEY(id),
> >>>>INDEX(pet_id)
> >>>>);
> >>>>INSERT INTO visits VALUES (1, 7, '1996-03-04', 'rabies shot');
> >>>>INSERT INTO visits VALUES (NULL, 8, '1996-03-04', 'rabies shot');
> >>>>INSERT INTO visits VALUES (NULL, 8, '1996-06-04', 'neutered');
> >>>>INSERT INTO visits VALUES (NULL, 7, '1996-09-04', 'spayed');
> >>>>
> >>>>CREATE TABLE visits_seq (
> >>>>seq INT(4) UNSIGNED NOT NULL
> >>>>);
> >>>>INSERT INTO visits_seq VALUES (5);
> >>>>
> >>>>
> >>>>The data is written correctly to the DB using the auto-incremented
> >>>>visit_id. The problem is that the getKey() function of the
> >>>>returned InsertRetval returns 0, not the id that was used for the
> >>>>insert. I wanted to use the value to update my cache directly without
> >>>>having to requery the DB for all this pet's visits. I am working around
> >>>>it by doing just that.
> >>>>
> >>>>
> >>>>I include below a relevant snippet from the INFO log:
> >>>>
> >>>>2003-05-22 22:53:37,966 INFO [petclinic.support.ClinicImpl$NewVisit] -
> >>>><Compiled OK>
> >>>>2003-05-22 22:53:37,996 INFO [petclinic.support.ClinicImpl$NewVisit] -
> >>>><Visit petId = 7>
> >>>>2003-05-22 22:53:38,006 INFO [com.interface21.jdbc.object.SqlUpdate] -
> >>>><Compiled OK>
> >>>>2003-05-22 22:53:38,016 INFO [com.interface21.jdbc.core.JdbcTemplate] -
> >>>><JDBCTemplate: update affected 1 rows>
> >>>>2003-05-22 22:53:38,016 INFO [com.interface21.jdbc.object.SqlUpdate] -
> >>>><1 rows affected by SQL update [update visits_seq set seq =
> >>>>last_insert_id(seq + 1)]>
> >>>>2003-05-22 22:53:38,026 INFO [com.interface21.jdbc.object.SqlFunction]
> >>>>- <Compiled OK>
> >>>>2003-05-22 22:53:38,036 INFO [com.interface21.jdbc.core.JdbcTemplate] -
> >>>><Executing SQL query using PreparedStatement:
> >>>>[PreparedStatementCreatorFactory.PreparedStatementCreatorImpl:
> >>>>sql={select last_insert_id()}: params={}]>
> >>>>2003-05-22 22:53:38,036 INFO [com.interface21.jdbc.core.JdbcTemplate] -
> >>>><JDBCTemplate: update affected
> >>>>com.interface21.jdbc.core.JdbcTemplate$InsertRetval@1ebe3f0 rows>
> >>>>2003-05-22 22:53:38,036 INFO [petclinic.support.ClinicImpl$NewVisit] -
> >>>><Visit id = 0 petId = 7>
> >>>>
> >>>>Note that the last line shows the visit_id == 0.
> >>>>Also note the odd output of the 2nd last line where instead of
> >>>>outputting the no. of rows affected it's printing a toString() of the
> >>>>InsertRetval !!!???
> >>>>
> >>>>
> >>>>Am I doing something wrong here ?
> >>>>
> >>>>
> >>>>Regards,
> >>>>
> >>>>Ken
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>
> >>>
> >
> >
> >
> >
> >
>
--
Isabelle Muszynski
Software Engineer
Zandweellaan 4
2660 Antwerpen
Belgium
Tel. 32-(0)3-830 18 54
Mobile: 32-(0)485 49 50 89
Email: isa...@me...
Website: www.meta-logix.com
|
|
From: JP P. <jp....@ti...> - 2003-05-23 22:46:49
|
Ken,
If the javadoc says that a column with auto_increment is to be used,
it's clearly a mistake.
But that doesn't solve the issue!
I used a similar approach with the old framework, but without the Binder
technique. I get manually the nextValue in each DAO and set its value
like the others parameters in the callback method and it works fine.
For now, the Binder mechanism has an open issue (ref last Isabelle's
post).
Regards,
Jean-Pierre
-----Message d'origine-----
De=A0: spr...@li...
[mailto:spr...@li...] De la
part de Ken Krebs
Envoy=E9=A0: samedi 24 mai 2003 00:09
=C0=A0: Isabelle Muszynski
Cc=A0: spr...@li...
Objet=A0: [Springframework-developer] SqlUpdate and insert functionality
Isabelle,
I don't understand this. I thought auto_increment on the visits id
column is what makes it work. The javadoc for MySQLMaxValueIncrementer
says that is to be used with an auto_increment column.
I tried removing the auto_increment as you suggested and it no longer
works.
Ken
As I said earlier:
"The data is written correctly to the DB using the auto-incremented=20
visit_id. The problem is that the getKey() function of the=20
returned InsertRetval returns 0, not the id that was used for the=20
insert. I wanted to use the value to update my cache directly without=20
having to requery the DB for all this pet's visits. I am working around=20
it by doing just that."
Isabelle Muszynski wrote:
Hi Ken,
Looking at the mail you sent me this morning (included below), in table
visits, column id is auto-increment, and it shouldn't be. Neither should
the sequence column be, which is correct in the code below.
The definition of column id should be "int not null primary key"
Does this help?
Isabelle
On Fri, May 23, 2003 at 09:04:01AM -0500, Ken Krebs wrote:
=20
Isabelle,
My key column isn't auto-incremented, only the actual id column is.
My latest code snapshot is attached.
Ken
Isabelle Muszynski wrote:
=20
Hi Ken,
Your key column should NOT be auto-increment.
If that doesn't solve the problem, let me know, and pls attach the code
so=20
I don't have top type it over. Will look at it tonight or tomorrow. I'll
also look into the strange log output, probably a stupid booboo.
Isabelle
On Thu, May 22, 2003 at 11:25:08PM -0500, Ken Krebs wrote:
=20
Hi Isabelle,
I have a problem using the following petclinic class that inserts a new=20
visit into the DB :
class NewVisit extends SqlUpdate {
=20
public NewVisit(DataSource ds) {
super(ds, "INSERT INTO visits VALUES(?,?,?,?)");
declareParameter(new SqlParameter(Types.INTEGER));
declareParameter(new SqlParameter(Types.INTEGER));
declareParameter(new SqlParameter(Types.DATE));
declareParameter(new SqlParameter(Types.VARCHAR));
compile();
}
=20
public int insert(Visit visit) {
KeyBinder keybinder =3D new KeyBinder() {
public void bind(PreparedStatement ps, Object obj)=20
throws SQLException {
ps.setObject(1, obj);
}
};
=20
MySQLMaxValueIncrementer incr =3D new=20
MySQLMaxValueIncrementer(getDataSource(), "visits_seq", "seq", 1);
=20
logger.info("Visit petId =3D " + visit.getPetId());
=20
Object[] objs =3D new Object[] {
null,
new Integer(visit.getPetId()),
visit.getVisitDate(),
visit.getDescription()
};
=20
JdbcTemplate.InsertRetval retVal =3D update(objs, keybinder,=20
incr, Integer.class);
visit.setId(((Integer) retVal.getKey()).intValue());
=20
logger.info("Visit id =3D " + visit.getId() + " petId =3D " + =
visit.getPetId());
=20
return retVal.getRowsAffected();
}
=20
}
My table definitions for visits and its sequencer are :
CREATE TABLE visits (
id INT(4) UNSIGNED NOT NULL AUTO_INCREMENT,
pet_id INT(4) UNSIGNED NOT NULL REFERENCES pets(id),
visit_date DATE,
description VARCHAR(255),
PRIMARY KEY(id),
INDEX(pet_id)
);
INSERT INTO visits VALUES (1, 7, '1996-03-04', 'rabies shot');
INSERT INTO visits VALUES (NULL, 8, '1996-03-04', 'rabies shot');
INSERT INTO visits VALUES (NULL, 8, '1996-06-04', 'neutered');
INSERT INTO visits VALUES (NULL, 7, '1996-09-04', 'spayed');
CREATE TABLE visits_seq (
seq INT(4) UNSIGNED NOT NULL
);
INSERT INTO visits_seq VALUES (5);
The data is written correctly to the DB using the auto-incremented=20
visit_id. The problem is that the getKey() function of the=20
returned InsertRetval returns 0, not the id that was used for the=20
insert. I wanted to use the value to update my cache directly without=20
having to requery the DB for all this pet's visits. I am working around=20
it by doing just that.
I include below a relevant snippet from the INFO log:
2003-05-22 22:53:37,966 INFO [petclinic.support.ClinicImpl$NewVisit] -=20
<Compiled OK>
2003-05-22 22:53:37,996 INFO [petclinic.support.ClinicImpl$NewVisit] -=20
<Visit petId =3D 7>
2003-05-22 22:53:38,006 INFO [com.interface21.jdbc.object.SqlUpdate] -=20
<Compiled OK>
2003-05-22 22:53:38,016 INFO [com.interface21.jdbc.core.JdbcTemplate] -=20
<JDBCTemplate: update affected 1 rows>
2003-05-22 22:53:38,016 INFO [com.interface21.jdbc.object.SqlUpdate] -=20
<1 rows affected by SQL update [update visits_seq set seq =3D=20
last_insert_id(seq + 1)]>
2003-05-22 22:53:38,026 INFO [com.interface21.jdbc.object.SqlFunction] -
<Compiled OK>
2003-05-22 22:53:38,036 INFO [com.interface21.jdbc.core.JdbcTemplate] -=20
<Executing SQL query using PreparedStatement:=20
[PreparedStatementCreatorFactory.PreparedStatementCreatorImpl:=20
sql=3D{select last_insert_id()}: params=3D{}]>
2003-05-22 22:53:38,036 INFO [com.interface21.jdbc.core.JdbcTemplate] -=20
<JDBCTemplate: update affected=20
com.interface21.jdbc.core.JdbcTemplate$InsertRetval@1ebe3f0 rows>
2003-05-22 22:53:38,036 INFO [petclinic.support.ClinicImpl$NewVisit] -=20
<Visit id =3D 0 petId =3D 7>
Note that the last line shows the visit_id =3D=3D 0.
Also note the odd output of the 2nd last line where instead of=20
outputting the no. of rows affected it's printing a toString() of the=20
InsertRetval !!!???
Am I doing something wrong here ?
Regards,
Ken
=20
=20
=20
=20
|
|
From: Ken K. <kk...@kk...> - 2003-05-23 22:14:26
|
Isabelle,
I don't understand this. I thought auto_increment on the visits id
column is what makes it work. The javadoc for MySQLMaxValueIncrementer
says that is to be used with an auto_increment column.
I tried removing the auto_increment as you suggested and it no longer works.
Ken
As I said earlier:
"The data is written correctly to the DB using the auto-incremented
visit_id. The problem is that the getKey() function of the
returned InsertRetval returns 0, not the id that was used for the
insert. I wanted to use the value to update my cache directly without
having to requery the DB for all this pet's visits. I am working around
it by doing just that."
Isabelle Muszynski wrote:
>Hi Ken,
>
>Looking at the mail you sent me this morning (included below), in table visits, column id is auto-increment, and it shouldn't be. Neither should the sequence column be, which is correct in the code below.
>
>The definition of column id should be "int not null primary key"
>
>Does this help?
>
>Isabelle
>
>On Fri, May 23, 2003 at 09:04:01AM -0500, Ken Krebs wrote:
>
>
>>Isabelle,
>>
>>My key column isn't auto-incremented, only the actual id column is.
>>
>>My latest code snapshot is attached.
>>
>>Ken
>>
>>
>>Isabelle Muszynski wrote:
>>
>>
>>
>>>Hi Ken,
>>>
>>>Your key column should NOT be auto-increment.
>>>
>>>If that doesn't solve the problem, let me know, and pls attach the code so
>>>I don't have top type it over. Will look at it tonight or tomorrow. I'll
>>>also look into the strange log output, probably a stupid booboo.
>>>
>>>Isabelle
>>>
>>>On Thu, May 22, 2003 at 11:25:08PM -0500, Ken Krebs wrote:
>>>
>>>
>>>
>>>
>>>>Hi Isabelle,
>>>>
>>>>I have a problem using the following petclinic class that inserts a new
>>>>visit into the DB :
>>>>
>>>> class NewVisit extends SqlUpdate {
>>>>
>>>> public NewVisit(DataSource ds) {
>>>> super(ds, "INSERT INTO visits VALUES(?,?,?,?)");
>>>> declareParameter(new SqlParameter(Types.INTEGER));
>>>> declareParameter(new SqlParameter(Types.INTEGER));
>>>> declareParameter(new SqlParameter(Types.DATE));
>>>> declareParameter(new SqlParameter(Types.VARCHAR));
>>>> compile();
>>>> }
>>>>
>>>> public int insert(Visit visit) {
>>>> KeyBinder keybinder = new KeyBinder() {
>>>> public void bind(PreparedStatement ps, Object obj)
>>>>throws SQLException {
>>>> ps.setObject(1, obj);
>>>> }
>>>> };
>>>>
>>>> MySQLMaxValueIncrementer incr = new
>>>>MySQLMaxValueIncrementer(getDataSource(), "visits_seq", "seq", 1);
>>>>
>>>> logger.info("Visit petId = " + visit.getPetId());
>>>>
>>>> Object[] objs = new Object[] {
>>>> null,
>>>> new Integer(visit.getPetId()),
>>>> visit.getVisitDate(),
>>>> visit.getDescription()
>>>> };
>>>>
>>>> JdbcTemplate.InsertRetval retVal = update(objs, keybinder,
>>>>incr, Integer.class);
>>>> visit.setId(((Integer) retVal.getKey()).intValue());
>>>>
>>>> logger.info("Visit id = " + visit.getId() + " petId = " +
>>>>visit.getPetId());
>>>>
>>>> return retVal.getRowsAffected();
>>>> }
>>>>
>>>> }
>>>>
>>>>My table definitions for visits and its sequencer are :
>>>>
>>>>CREATE TABLE visits (
>>>>id INT(4) UNSIGNED NOT NULL AUTO_INCREMENT,
>>>>pet_id INT(4) UNSIGNED NOT NULL REFERENCES pets(id),
>>>>visit_date DATE,
>>>>description VARCHAR(255),
>>>>PRIMARY KEY(id),
>>>>INDEX(pet_id)
>>>>);
>>>>INSERT INTO visits VALUES (1, 7, '1996-03-04', 'rabies shot');
>>>>INSERT INTO visits VALUES (NULL, 8, '1996-03-04', 'rabies shot');
>>>>INSERT INTO visits VALUES (NULL, 8, '1996-06-04', 'neutered');
>>>>INSERT INTO visits VALUES (NULL, 7, '1996-09-04', 'spayed');
>>>>
>>>>CREATE TABLE visits_seq (
>>>>seq INT(4) UNSIGNED NOT NULL
>>>>);
>>>>INSERT INTO visits_seq VALUES (5);
>>>>
>>>>
>>>>The data is written correctly to the DB using the auto-incremented
>>>>visit_id. The problem is that the getKey() function of the
>>>>returned InsertRetval returns 0, not the id that was used for the
>>>>insert. I wanted to use the value to update my cache directly without
>>>>having to requery the DB for all this pet's visits. I am working around
>>>>it by doing just that.
>>>>
>>>>
>>>>I include below a relevant snippet from the INFO log:
>>>>
>>>>2003-05-22 22:53:37,966 INFO [petclinic.support.ClinicImpl$NewVisit] -
>>>><Compiled OK>
>>>>2003-05-22 22:53:37,996 INFO [petclinic.support.ClinicImpl$NewVisit] -
>>>><Visit petId = 7>
>>>>2003-05-22 22:53:38,006 INFO [com.interface21.jdbc.object.SqlUpdate] -
>>>><Compiled OK>
>>>>2003-05-22 22:53:38,016 INFO [com.interface21.jdbc.core.JdbcTemplate] -
>>>><JDBCTemplate: update affected 1 rows>
>>>>2003-05-22 22:53:38,016 INFO [com.interface21.jdbc.object.SqlUpdate] -
>>>><1 rows affected by SQL update [update visits_seq set seq =
>>>>last_insert_id(seq + 1)]>
>>>>2003-05-22 22:53:38,026 INFO [com.interface21.jdbc.object.SqlFunction] -
>>>><Compiled OK>
>>>>2003-05-22 22:53:38,036 INFO [com.interface21.jdbc.core.JdbcTemplate] -
>>>><Executing SQL query using PreparedStatement:
>>>>[PreparedStatementCreatorFactory.PreparedStatementCreatorImpl:
>>>>sql={select last_insert_id()}: params={}]>
>>>>2003-05-22 22:53:38,036 INFO [com.interface21.jdbc.core.JdbcTemplate] -
>>>><JDBCTemplate: update affected
>>>>com.interface21.jdbc.core.JdbcTemplate$InsertRetval@1ebe3f0 rows>
>>>>2003-05-22 22:53:38,036 INFO [petclinic.support.ClinicImpl$NewVisit] -
>>>><Visit id = 0 petId = 7>
>>>>
>>>>Note that the last line shows the visit_id == 0.
>>>>Also note the odd output of the 2nd last line where instead of
>>>>outputting the no. of rows affected it's printing a toString() of the
>>>>InsertRetval !!!???
>>>>
>>>>
>>>>Am I doing something wrong here ?
>>>>
>>>>
>>>>Regards,
>>>>
>>>>Ken
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>
>
>
>
>
|
|
From: JP P. <jp....@ti...> - 2003-05-23 20:20:51
|
Hi, Excuse me from disturbing from fundamental issues like the KeyBinder posted by Isabelle and the broken tests I've just posted. As I talked about, I have added three files: In src: - com.interface21.util.PagedListAutoHolder.java (Class derived from PagedListHolder) - com.interface21.util.PagedListSourceProvider.java=A0(Interface) in test: - com.interface21.util.PagedListAutoHolderTests.java (Class) This all for easy use of a more powerfull paged List. The javadoc and eventually test source will normally suffice to understand the use. Nevertheless, if I will not be impacted by the current test issues, I will try to provide a tiny sample application for demonstrating. After 0.8 will be released, I could have some help for rewieving the javadoc comments as my English is very far from perfect. Regards, ______________________________ Jean-Pierre Pawlak jp....@ti... =A0 |
|
From: JP P. <jp....@ti...> - 2003-05-23 20:00:03
|
Hi, I have currently the WebApplicationContextTestSuite broken with this report: Testcase: testWebApplicationContextExposedAsServletContextAttribute took 0,063 sec FAILED WebApplicationContext exposed in ServletContext as attribute junit.framework.AssertionFailedError: WebApplicationContext exposed in ServletContext as attribute at com.interface21.web.context.WebApplicationContextTestSuite.testWebApplic ationContextExposedAsServletContextAttribute(WebApplicationContextTestSu ite.java:79) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.jav a:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessor Impl.java:25) With a from scratch download, it is worse, the first testSuite fails: Testsuite: com.interface21.aop.framework.AopProxyTests$TrapInvocationInterceptor Tests run: 1, Failures: 1, Errors: 0, Time elapsed: 0,032 sec Testcase: warning took 0,016 sec FAILED Class com.interface21.aop.framework.AopProxyTests$TrapInvocationInterceptor has no public constructor TestCase(String name) junit.framework.AssertionFailedError: Class com.interface21.aop.framework.AopProxyTests$TrapInvocationInterceptor has no public constructor TestCase(String name) Testcase: warning Regards,=20 ________________________________=A0 Jean-Pierre Pawlak jp....@ti... =A0 |
|
From: Isabelle M. <isa...@me...> - 2003-05-23 18:41:32
|
Hi everyone, Having finally managed to get the livetest cases to compile (thanks to Rod's laser eyes), I've discovered a fundamental problem in SqlOperation.compileInternal(). When using key generation, part of the binding is deferred to the KeyBinder callback interface, and so SqlUpdate.compile() fails because one less parameter has been bound than declared. So somehow compile must be able to sense that a key generator is being used and then accept num params - 1. I can think of a number of solutions, none of which I particularly like : (1) a useGenerator property which must be set/unset as necessary. The bad thing about this one is that JIT compilation won't work. (2) introduce a new ctor with a boolean arg, usesKeyGenerator; but then this screws up reuse of the same SqlUpdate. (3) declare a usesKeyGenerator method(), which returns false in SqlUpdate, and create a SqlInsert that derives from SqlUpdate and implements the method to return true. In SqlUpdate's compileInternal, call usesKeyGenerator and act accordingly. Of the bunch, I think (3) is the least evil. Does everyone agree? Or does anyone have a bright idea of how to solve this differently? Isabelle -- Isabelle Muszynski Software Engineer Zandweellaan 4 2660 Antwerpen Belgium Tel. 32-(0)3-830 18 54 Mobile: 32-(0)485 49 50 89 Email: isa...@me... Website: www.meta-logix.com |
|
From: Rod J. <rod...@in...> - 2003-05-23 17:57:44
|
Sounds good. I didn't realise this about JDO. I doubt there are any specific threading issues: a race condition would just initialize (correctly) twice, I guess. Rod ----- Original Message ----- From: <tri...@tr...> To: "Rod Johnson" <rod...@in...> Cc: <spr...@li...> Sent: Friday, May 23, 2003 6:49 PM Subject: Re: [Springframework-developer] Code changes for 0.8? > Rod, > > A JDO Query supports compile(), but if the Query is not compiled when execute() > is called, then the Query is compiled automatically. I think we should provide > the same functionality. I have to look closer at the code to determine if there > are any threading issues we have to address. > > --Tomas > > > > While we are on the subject of JDBC. Do we really have to require an > > explicit > > > compile for the RdbmsOperation and its subclasses. Currently we throw > > > InvalidDataAccessApiUsageException when we try to use an operation that > > has > > > not been comiled. We could just as easily execute the compile() at that > > > point, since we know what the problem is. > > > > Good question. I guess I was concerned about thread safety implications of > > compiling lazily. What do you think? > > > > Certainly there'd be a bonus in making the API slightly easier to use. > > > > Regards, > > Rod > > > > > > > > > > |
|
From: Rod J. <rod...@in...> - 2003-05-23 17:54:04
|
> While we are on the subject of JDBC. Do we really have to require an explicit > compile for the RdbmsOperation and its subclasses. Currently we throw > InvalidDataAccessApiUsageException when we try to use an operation that has > not been comiled. We could just as easily execute the compile() at that > point, since we know what the problem is. Good question. I guess I was concerned about thread safety implications of compiling lazily. What do you think? Certainly there'd be a bonus in making the API slightly easier to use. Regards, Rod |
|
From: <tri...@tr...> - 2003-05-23 17:48:59
|
Rod, A JDO Query supports compile(), but if the Query is not compiled when execute() is called, then the Query is compiled automatically. I think we should provide the same functionality. I have to look closer at the code to determine if there are any threading issues we have to address. --Tomas > > While we are on the subject of JDBC. Do we really have to require an > explicit > > compile for the RdbmsOperation and its subclasses. Currently we throw > > InvalidDataAccessApiUsageException when we try to use an operation that > has > > not been comiled. We could just as easily execute the compile() at that > > point, since we know what the problem is. > > Good question. I guess I was concerned about thread safety implications of > compiling lazily. What do you think? > > Certainly there'd be a bonus in making the API slightly easier to use. > > Regards, > Rod > > > |
|
From: Isabelle M. <isa...@me...> - 2003-05-23 16:17:26
|
Hi Ken,
I've been able to reproduce your problem. So I'm going to look further into it.
Isabelle
On Fri, May 23, 2003 at 09:24:45AM +0200, Isabelle Muszynski wrote:
> Hi Ken,
>
> Your key column should NOT be auto-increment.
>
> If that doesn't solve the problem, let me know, and pls attach the code so I don't have top type it over. Will look at it tonight or tomorrow. I'll also look into the strange log output, probably a stupid booboo.
>
> Isabelle
>
> On Thu, May 22, 2003 at 11:25:08PM -0500, Ken Krebs wrote:
> > Hi Isabelle,
> >
> > I have a problem using the following petclinic class that inserts a new
> > visit into the DB :
> >
> > class NewVisit extends SqlUpdate {
> >
> > public NewVisit(DataSource ds) {
> > super(ds, "INSERT INTO visits VALUES(?,?,?,?)");
> > declareParameter(new SqlParameter(Types.INTEGER));
> > declareParameter(new SqlParameter(Types.INTEGER));
> > declareParameter(new SqlParameter(Types.DATE));
> > declareParameter(new SqlParameter(Types.VARCHAR));
> > compile();
> > }
> >
> > public int insert(Visit visit) {
> > KeyBinder keybinder = new KeyBinder() {
> > public void bind(PreparedStatement ps, Object obj)
> > throws SQLException {
> > ps.setObject(1, obj);
> > }
> > };
> >
> > MySQLMaxValueIncrementer incr = new
> > MySQLMaxValueIncrementer(getDataSource(), "visits_seq", "seq", 1);
> >
> > logger.info("Visit petId = " + visit.getPetId());
> >
> > Object[] objs = new Object[] {
> > null,
> > new Integer(visit.getPetId()),
> > visit.getVisitDate(),
> > visit.getDescription()
> > };
> >
> > JdbcTemplate.InsertRetval retVal = update(objs, keybinder,
> > incr, Integer.class);
> > visit.setId(((Integer) retVal.getKey()).intValue());
> >
> > logger.info("Visit id = " + visit.getId() + " petId = " +
> > visit.getPetId());
> >
> > return retVal.getRowsAffected();
> > }
> >
> > }
> >
> > My table definitions for visits and its sequencer are :
> >
> > CREATE TABLE visits (
> > id INT(4) UNSIGNED NOT NULL AUTO_INCREMENT,
> > pet_id INT(4) UNSIGNED NOT NULL REFERENCES pets(id),
> > visit_date DATE,
> > description VARCHAR(255),
> > PRIMARY KEY(id),
> > INDEX(pet_id)
> > );
> > INSERT INTO visits VALUES (1, 7, '1996-03-04', 'rabies shot');
> > INSERT INTO visits VALUES (NULL, 8, '1996-03-04', 'rabies shot');
> > INSERT INTO visits VALUES (NULL, 8, '1996-06-04', 'neutered');
> > INSERT INTO visits VALUES (NULL, 7, '1996-09-04', 'spayed');
> >
> > CREATE TABLE visits_seq (
> > seq INT(4) UNSIGNED NOT NULL
> > );
> > INSERT INTO visits_seq VALUES (5);
> >
> >
> > The data is written correctly to the DB using the auto-incremented
> > visit_id. The problem is that the getKey() function of the
> > returned InsertRetval returns 0, not the id that was used for the
> > insert. I wanted to use the value to update my cache directly without
> > having to requery the DB for all this pet's visits. I am working around
> > it by doing just that.
> >
> >
> > I include below a relevant snippet from the INFO log:
> >
> > 2003-05-22 22:53:37,966 INFO [petclinic.support.ClinicImpl$NewVisit] -
> > <Compiled OK>
> > 2003-05-22 22:53:37,996 INFO [petclinic.support.ClinicImpl$NewVisit] -
> > <Visit petId = 7>
> > 2003-05-22 22:53:38,006 INFO [com.interface21.jdbc.object.SqlUpdate] -
> > <Compiled OK>
> > 2003-05-22 22:53:38,016 INFO [com.interface21.jdbc.core.JdbcTemplate] -
> > <JDBCTemplate: update affected 1 rows>
> > 2003-05-22 22:53:38,016 INFO [com.interface21.jdbc.object.SqlUpdate] -
> > <1 rows affected by SQL update [update visits_seq set seq =
> > last_insert_id(seq + 1)]>
> > 2003-05-22 22:53:38,026 INFO [com.interface21.jdbc.object.SqlFunction] -
> > <Compiled OK>
> > 2003-05-22 22:53:38,036 INFO [com.interface21.jdbc.core.JdbcTemplate] -
> > <Executing SQL query using PreparedStatement:
> > [PreparedStatementCreatorFactory.PreparedStatementCreatorImpl:
> > sql={select last_insert_id()}: params={}]>
> > 2003-05-22 22:53:38,036 INFO [com.interface21.jdbc.core.JdbcTemplate] -
> > <JDBCTemplate: update affected
> > com.interface21.jdbc.core.JdbcTemplate$InsertRetval@1ebe3f0 rows>
> > 2003-05-22 22:53:38,036 INFO [petclinic.support.ClinicImpl$NewVisit] -
> > <Visit id = 0 petId = 7>
> >
> > Note that the last line shows the visit_id == 0.
> > Also note the odd output of the 2nd last line where instead of
> > outputting the no. of rows affected it's printing a toString() of the
> > InsertRetval !!!???
> >
> >
> > Am I doing something wrong here ?
> >
> >
> > Regards,
> >
> > Ken
> >
> >
> >
>
> --
> Isabelle Muszynski
> Software Engineer
> Zandweellaan 4
> 2660 Antwerpen
> Belgium
> Tel. 32-(0)3-830 18 54
> Mobile: 32-(0)485 49 50 89
> Email: isa...@me...
> Website: www.meta-logix.com
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: ObjectStore.
> If flattening out C++ or Java code to make your application fit in a
> relational database is painful, don't do it! Check out ObjectStore.
> Now part of Progress Software. http://www.objectstore.net/sourceforge
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>
>
--
Isabelle Muszynski
Software Engineer
Zandweellaan 4
2660 Antwerpen
Belgium
Tel. 32-(0)3-830 18 54
Mobile: 32-(0)485 49 50 89
Email: isa...@me...
Website: www.meta-logix.com
|
|
From: <rod...@in...> - 2003-05-23 16:15:52
|
>My question is what is the difference between Spring AOP and AspectJ? What spaces are each trying to fill? etc. Quick reply... I'll have to do an AOP FAQ at some point. 1. AspectJ is a language extension. Spring AOP uses dynamic proxies, so there's no language extensions and no special compilation steps. Spring AOP enables aspects to be used with beans in Spring bean factories. Thus use of AOP is hidden behind interfaces as an implementation detail. AspectJ is much more powerful than any other AOP solution (as it introduces new keywords and constructs) but there's a learning curve and it's arguably *too* powerful (it's possible to do things that might be problematic in large projects). 2. JBoss AOP is promising but it's linked to the container. To my mind, this is wrong. I don't want EJB to tie me to the container without good reason; I also don't want a container- only AOP solution. Also it means giving up J2EE portability. Spring AOP doesn't do anything weird with class loaders, so it works in any container. Also, JBoss AOP is more complex to use, from what I've seen. It's more powerful in that it allows you to intercept field access (as does AspectJ), but IMHO this breaks good practice anyway. (Just because we're using AOP, we don't want to throw out encapsulation.) 3. The most similar product is probably Jon Tirsen's Nanning (SF). Jon and I even worked on an interoperability API, enabling the same interceptors to run in each AOP framework, but Jon isn't going to implement it in the near future (although Spring does already). Nanning is pretty similar in what it can do, although it isn't integrated into a bigger picture as is Spring AOP. Spring AOP is about pragmatic use of AOP, right now. Declarative transaction management is already available, and a good example of what can be done. Regards, Rod |
|
From: Travis C. <tra...@le...> - 2003-05-23 15:46:14
|
I have been reading a lot of the old wrox message board in preparation = to offer myself as help on the coding effort wherever I can fit in. On = the message board is where I saw the start of the discussion of AOP. I = have read a few things regarding AOP and its seems extremely promising = (especially what JBoss 4.0 could be). My first reading of AOP started = with articles about AspectJ. My question is what is the difference = between Spring AOP and AspectJ? What spaces are each trying to fill? = etc. Thanks, Travis -----Original Message----- From: Kopylenko, Dmitry [mailto:dko...@ac...] Sent: Friday, May 23, 2003 7:41 AM To: 'spring-dev-list' Subject: [Springframework-developer] AOP Rod, everyone, I just want to report that we've started to use AOP framework for one of = our big web app. projects. We've successfully implemented and incorporated aspects like "MailConfirmationInterceptor", "AuditTrailInterceptor", "DebugInterceptor" to name a few. More to come.... The AOP paradigm is really going to be big IMO. Also, here is the list of Spring components/sub-frameworks we're using = for this project: * BeanFactory * WebApplicationContext * JDBC * Tx infrastructure (via declarative aop approach) * MVC web framework * AOP Regards, Dmitriy. ------------------------------------------------------- This SF.net email is sponsored by: ObjectStore. If flattening out C++ or Java code to make your application fit in a relational database is painful, don't do it! Check out ObjectStore. Now part of Progress Software. http://www.objectstore.net/sourceforge _______________________________________________ Springframework-developer mailing list Spr...@li... https://lists.sourceforge.net/lists/listinfo/springframework-developer |
1239 messages has been excluded from this view by a project administrator.
