Re: Fw: [Springframework-developer] insert functionality in jdbc package

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

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
> 
>