Menu
▾
▴
springframework-developer
|
From: Thomas R. <tri...@tr...> - 2003-04-16 16:30:38
|
Rod, I'm pretty much in agreement with your position. What initially attracted me to your JDBC framework was that it freed me from all the exception/connection closing issues. Another plus is that it lets you work in a more object oriented fashion. I don't mind adding layers on top of the basic Spring JDBC functionality, that would provide a comlete set of the insert/select/update/delete functionality in a nice and easy to use abstraction. For the primary key generation I like to use the functionality that the database provides and isolate it in a java class that can be swapped for a different implementation when you switch to a different database platform. What I like to do for Oracle is use a sequence, and have an insert-trigger that will look up the next value in the sequence if no primarky key value is supplied. Then I also have a database function that gets the next value from the sequence and returns it. This function can be used from any PL/SQL code that insert rows. On top of this I would have a "getNextKey" method to access this database function in a Java class that wraps any database specific code. Thomas > Isabelle, > > You make a valid point about not wanting to need another product for just > one problem. > > My view is that > - we don't want to get into full-blown O/R mapping > - BUT there is scope in building more JDBC-based functionality and > abstractions on top of the Spring JDBC way of doing things. To my mind the > central value proposition of Spring JDBC is the exception hierarchy and way > it frees developers of the tedious and error-prone tasks of raw JDBC. > Additional features can validly be layered on top. > > So I think you should propose how you think we should add the insert > functionality, perhaps even implement it, so we can discuss it and > incorporate it if we're all comfortable with it. I think it's > - important that any abstraction shouldn't impose potential inefficiency, > and should allow the use of efficient RDBMS functions like Oracle sequences > - important that it should be compatible with JDBC 3.0 moving forward. > > Thomas, do you have any thoughts on this? > > Regards, > Rod > > > Personally, I don't think I'd want to commit to yet another framework such > as hibernate for ex. in the project at work we're planning to do with > spring. Most of what we need for jdbc is in spring, except for the insert > functionality. Even with oracle, I don't like the idea of having to write a > stored procedure for every single insert, I'd probably opt for the > additional cost of a select next_val from dual in jdbc code (i.e. instead of > just doing an insert, first retrieve the key val then do the insert). The > main problem is with db's that don't have sequences, and if we agree to live > with holes in the primary key sequences we can implement an algorithm where > some sort of key manager per VM reserves a range of key values per table. > > > > Isabelle > > > > > > ------------------------------------------------------- > This sf.net email is sponsored by:ThinkGeek > Welcome to geek heaven. > http://thinkgeek.com/sf > _______________________________________________ > Springframework-developer mailing list > Spr...@li... > https://lists.sourceforge.net/lists/listinfo/springframework-developer > > |
|
From: Isabelle M. <isa...@me...> - 2003-05-19 06:46:17
|
Hello Kees, In the current framework, you indeed should use update for inserts. And the special overloaded forms of update with a KeyBinder argument for the key generation. Isabelle On Sun, May 18, 2003 at 11:16:18AM +0200, kees jan voogd wrote: > Hi Isabelle, > > > For what it's worth I agree with you. You just can't put everything in > stored procedures. Omission of inserts from the framework was a mistake and > an omission in an ohterwise very readable book. > > For your solotion I would not look into pk (or guid) generation right away. > This is just a part of the inserts. And a very nasty issue one at that too. > > I've been using the JdbcTemplate's update methods for inserts. The only iffy > thing there is that the method call is update instead of insert (logged as > update aswell). A change there would be sufficient (imho). > > As for pk generation i've been using the select SEQ.nextval from dual bit. I > built numbergeneratator class doing these selects. (based on just table name > SEQ_PK_table and SEQ_table_colum for other sequences). > > Complete integration of pk generatation into the framwork would provide > quite a lot of problems (more then they would solve ??). > > > > anyway, > > > > Goodluck ! > > > > KJ > > > > > > > > "Isabelle Muszynski" <isa...@me...> wrote in message > news:<200...@lu...>... > > Will have a look at how we could best incorporate insert functionality and > will get back to you. > > > > Isabelle > > > > > > On Wed, Apr 16, 2003 at 02:10:56PM +0100, Rod Johnson wrote: > > > Isabelle, > > > > > > You make a valid point about not wanting to need another product for > just > > > one problem. > > > > > > My view is that > > > - we don't want to get into full-blown O/R mapping > > > - BUT there is scope in building more JDBC-based functionality and > > > abstractions on top of the Spring JDBC way of doing things. To my mind > the > > > central value proposition of Spring JDBC is the exception hierarchy and > way > > > it frees developers of the tedious and error-prone tasks of raw JDBC. > > > Additional features can validly be layered on top. > > > > > > So I think you should propose how you think we should add the insert > > > functionality, perhaps even implement it, so we can discuss it and > > > incorporate it if we're all comfortable with it. I think it's > > > - important that any abstraction shouldn't impose potential > inefficiency, > > > and should allow the use of efficient RDBMS functions like Oracle > sequences > > > - important that it should be compatible with JDBC 3.0 moving forward. > > > > > > Thomas, do you have any thoughts on this? > > > > > > Regards, > > > Rod > > > > > > > Personally, I don't think I'd want to commit to yet another framework > such > > > as hibernate for ex. in the project at work we're planning to do with > > > spring. Most of what we need for jdbc is in spring, except for the > insert > > > functionality. Even with oracle, I don't like the idea of having to > write a > > > stored procedure for every single insert, I'd probably opt for the > > > additional cost of a select next_val from dual in jdbc code (i.e. > instead of > > > just doing an insert, first retrieve the key val then do the insert). > The > > > main problem is with db's that don't have sequences, and if we agree to > live > > > with holes in the primary key sequences we can implement an algorithm > where > > > some sort of key manager per VM reserves a range of key values per > table. > > > > > > > > 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 > > > > > > ------------------------------------------------------- > > This sf.net email is sponsored by:ThinkGeek > > Welcome to geek heaven. > > http://thinkgeek.com/sf > --- > Outgoing mail is certified Virus Free. > Checked by AVG anti-virus system (http://www.grisoft.com). > Version: 6.0.481 / Virus Database: 277 - Release Date: 13/05/03 > > > -- 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: Ken K. <kk...@kk...> - 2003-05-19 14:06:38
|
Isabelle, Is there any high level (com.interface21.jdbc.object) support for Insert functionality ??? I've seen some comments about it being incorporated while browsing the CVS for SqlUpdate rev 1.4 and SqlOperation rev 1.4 but I see no actual differences supporting it. Is this planned for later ? Ken |
|
From: Isabelle M. <isa...@me...> - 2003-05-19 14:16:58
|
Hi Ken, It's all hidden under update. There are some new update methods that take a KeyBinder, those are the ones that use key auto-generation and return you the value of the generated key. For an insert without auto key generation, you can just use the update, passing it an INSERT INTO ... Isabelle On Mon, May 19, 2003 at 09:01:29AM -0500, Ken Krebs wrote: > Isabelle, > > Is there any high level (com.interface21.jdbc.object) support for Insert > functionality ??? > > I've seen some comments about it being incorporated while browsing the > CVS for SqlUpdate rev 1.4 and SqlOperation rev 1.4 but I see no actual > differences supporting it. > > Is this planned for later ? > > 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: Ken K. <kk...@kk...> - 2003-05-19 14:37:57
|
Isabelle, I don't see any update methods in SqlUpdate that take a KeyBinder. Ken Isabelle Muszynski wrote: >Hi Ken, > >It's all hidden under update. There are some new update methods that take a KeyBinder, those are the ones that use key auto-generation and return you the value of the generated key. >For an insert without auto key generation, you can just use the update, passing it an INSERT INTO ... > > >Isabelle > >On Mon, May 19, 2003 at 09:01:29AM -0500, Ken Krebs wrote: > > >>Isabelle, >> >>Is there any high level (com.interface21.jdbc.object) support for Insert >>functionality ??? >> >>I've seen some comments about it being incorporated while browsing the >>CVS for SqlUpdate rev 1.4 and SqlOperation rev 1.4 but I see no actual >>differences supporting it. >> >>Is this planned for later ? >> >>Ken >> >> >> >> >> >> > > > |
|
From: Ken K. <kk...@kk...> - 2003-05-20 12:43:06
|
Isabelle, Are there any plans to add insert functionality to the higher level part of the framework ? It seems inconsistent to me to force developers to use the lower level abstractions when I would think we would want to emphasize the higher level abstractions. Ken Isabelle Muszynski wrote: >Ken, > >Sorry, the methods are in JdbcTemplate. Have a look at the livetests directory. > >Isabelle > >On Mon, May 19, 2003 at 09:32:44AM -0500, Ken Krebs wrote: > > >>Isabelle, >> >>I don't see any update methods in SqlUpdate that take a KeyBinder. >> >>Ken >> >> >> >>Isabelle Muszynski wrote: >> >> >> >>>Hi Ken, >>> >>>It's all hidden under update. There are some new update methods that take >>>a KeyBinder, those are the ones that use key auto-generation and return >>>you the value of the generated key. >>>For an insert without auto key generation, you can just use the update, >>>passing it an INSERT INTO ... >>> >>> >>>Isabelle >>> >>>On Mon, May 19, 2003 at 09:01:29AM -0500, Ken Krebs wrote: >>> >>> >>> >>> >>>>Isabelle, >>>> >>>>Is there any high level (com.interface21.jdbc.object) support for Insert >>>>functionality ??? >>>> >>>>I've seen some comments about it being incorporated while browsing the >>>>CVS for SqlUpdate rev 1.4 and SqlOperation rev 1.4 but I see no actual >>>>differences supporting it. >>>> >>>>Is this planned for later ? >>>> >>>>Ken >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>> >>> >>> > > > |
|
From: Ken K. <kk...@kk...> - 2003-05-20 15:17:34
|
Isabelle, Thanks for giving it your attention. Your timing is not a problem for me. I will probably be implementing all the vets use cases using the jdbc.core classes anyway as Rod wants to show some of these types of examples in this demo-app. Ken Isabelle Muszynski wrote: >Hi Ken, > >I'll have a look at it, but it may have to wait until the weekend. However, I'll do my best to do it sooner. > >Isabelle > >On Tue, May 20, 2003 at 07:38:00AM -0500, Ken Krebs wrote: > > >>Isabelle, >> >>Are there any plans to add insert functionality to the higher level part >>of the framework ? >> >>It seems inconsistent to me to force developers to use the lower level >>abstractions when I would think we would want to emphasize the higher >>level abstractions. >> >>Ken >> >>Isabelle Muszynski wrote: >> >> >> >>>Ken, >>> >>>Sorry, the methods are in JdbcTemplate. Have a look at the livetests >>>directory. >>> >>>Isabelle >>> >>>On Mon, May 19, 2003 at 09:32:44AM -0500, Ken Krebs wrote: >>> >>> >>> >>> >>>>Isabelle, >>>> >>>>I don't see any update methods in SqlUpdate that take a KeyBinder. >>>> >>>>Ken >>>> >>>> >>>> >>>>Isabelle Muszynski wrote: >>>> >>>> >>>> >>>> >>>> >>>>>Hi Ken, >>>>> >>>>>It's all hidden under update. There are some new update methods that >>>>>take a KeyBinder, those are the ones that use key auto-generation and >>>>>return you the value of the generated key. >>>>>For an insert without auto key generation, you can just use the update, >>>>>passing it an INSERT INTO ... >>>>> >>>>> >>>>>Isabelle >>>>> >>>>>On Mon, May 19, 2003 at 09:01:29AM -0500, Ken Krebs wrote: >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>>>Isabelle, >>>>>> >>>>>>Is there any high level (com.interface21.jdbc.object) support for >>>>>>Insert functionality ??? >>>>>> >>>>>>I've seen some comments about it being incorporated while browsing the >>>>>>CVS for SqlUpdate rev 1.4 and SqlOperation rev 1.4 but I see no actual >>>>>>differences supporting it. >>>>>> >>>>>>Is this planned for later ? >>>>>> >>>>>>Ken >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>>> >>>>> >>> >>> >>> > > > |
|
From: Isabelle M. <isa...@me...> - 2003-04-16 16:51:21
|
This is pretty much the way we usually do things around here as well. For the trigger and PL-SQL agnostic, I'd suggest providing full keygen functionality in the JDBC package. Then everyone can pick and choose what suits them best. Isabelle On Wed, Apr 16, 2003 at 12:30:33PM -0400, Thomas Risberg wrote: > Rod, > > I'm pretty much in agreement with your position. > > What initially attracted me to your JDBC framework was that it freed me > from all the exception/connection closing issues. Another plus is that > it lets you work in a more object oriented fashion. I don't mind adding > layers on top of the basic Spring JDBC functionality, that would provide > a comlete set of the insert/select/update/delete functionality in a nice > and easy to use abstraction. > > For the primary key generation I like to use the functionality that the > database provides and isolate it in a java class that can be swapped for > a different implementation when you switch to a different database > platform. > > What I like to do for Oracle is use a sequence, and have an > insert-trigger that will look up the next value in the sequence if no > primarky key value is supplied. Then I also have a database function > that gets the next value from the sequence and returns it. This > function can be used from any PL/SQL code that insert rows. On top of > this I would have a "getNextKey" method to access this database function > in a Java class that wraps any database specific code. > > Thomas > > > > Isabelle, > > > > You make a valid point about not wanting to need another product for just > > one problem. > > > > My view is that > > - we don't want to get into full-blown O/R mapping > > - BUT there is scope in building more JDBC-based functionality and > > abstractions on top of the Spring JDBC way of doing things. To my mind the > > central value proposition of Spring JDBC is the exception hierarchy > and way > > it frees developers of the tedious and error-prone tasks of raw JDBC. > > Additional features can validly be layered on top. > > > > So I think you should propose how you think we should add the insert > > functionality, perhaps even implement it, so we can discuss it and > > incorporate it if we're all comfortable with it. I think it's > > - important that any abstraction shouldn't impose potential inefficiency, > > and should allow the use of efficient RDBMS functions like Oracle > sequences > > - important that it should be compatible with JDBC 3.0 moving forward. > > > > Thomas, do you have any thoughts on this? > > > > Regards, > > Rod > > > > > Personally, I don't think I'd want to commit to yet another > framework such > > as hibernate for ex. in the project at work we're planning to do with > > spring. Most of what we need for jdbc is in spring, except for the insert > > functionality. Even with oracle, I don't like the idea of having to > write a > > stored procedure for every single insert, I'd probably opt for the > > additional cost of a select next_val from dual in jdbc code (i.e. > instead of > > just doing an insert, first retrieve the key val then do the insert). The > > main problem is with db's that don't have sequences, and if we agree > to live > > with holes in the primary key sequences we can implement an algorithm > where > > some sort of key manager per VM reserves a range of key values per table. > > > > > > Isabelle > > > > > > > > > > > > ------------------------------------------------------- > > This sf.net email is sponsored by:ThinkGeek > > Welcome to geek heaven. > > http://thinkgeek.com/sf > > _______________________________________________ > > Springframework-developer mailing list > > Spr...@li... > > https://lists.sourceforge.net/lists/listinfo/springframework-developer > > > > > > > > ------------------------------------------------------- > This sf.net email is sponsored by:ThinkGeek > Welcome to geek heaven. > http://thinkgeek.com/sf > _______________________________________________ > 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 |
