Re: [Springframework-developer] src for long keys

SourceForge Headquarters 1320 Columbia Street Suite 310 San Diego, CA 92101 +1 (858) 422-6466

Hi Thomas,

I guess you're right. Even if someone declares the key as a NUMBER, it makes no sense to retrieve it as a Double. 

Isabelle

On Sat, May 03, 2003 at 02:29:20PM -0400, Thomas Risberg wrote:
> Isabelle,
> 
> For NUMERIC we would be better off mapping to BigDecimal and 
> use .longValue() or just use getLong().  Floats and Doubles are not 
> reliably re-cast to a long for very large numbers so their use is 
> limited.
> 
> I don't see why we would need to support anything other that int, long 
> and String as return values.
> 
> Thomas
> 
> P.S.
> 
> I think you just replied to my e-mail address and not the list's - 
> here is the message:
> 
> > Hi Thomas, Jean-Pierre,
> > 
> > If you don't mind adding Jean-Pierre's code, please do. I'm working 
> on some code samples for the tutorial.
> > I agree that Long's make sense, I was going to do it but then it 
> slipped my mind.
> > 
> > The Double return value is there because of the practice of using 
> NUMERIC columns for sequences.
> > 
> > As for retrieving bunches of keys at once, and then adding them out 
> one by one, I agree that that makes sense as well. As a matter of fact 
> it was raised in the mailing list when we first talked about insert 
> functionality and key generation, I remember I referred to an open 
> source project that does just that. It's not that complicated to do. 
> Jean-Pierre, if you feel like doing it, why don't you go ahead, and 
> then either Rod can give you commit access or one of us can check it 
> in for you.
> > 
> > I completely agree on select max(id) + 1, it's very bad. I put in a 
> code comment that explains why, but it's better than nothing for 
> databases we do not have specific code for.
> > 
> > Isabelle
> > 
> > On Sat, May 03, 2003 at 11:36:18AM -0400, Thomas Risberg wrote:
> > > Jean-Pierre,
> > > 
> > > Thanks for your changes.  I think adding long as a return value 
> has been
> > >  planned, but it was never implemented.  Isabelle, do you you want 
> to
> > > make these changes or do you want me to do it?  I'm modifying a few
> > > other jdbc classes this weekend, so I don't mind adding these 
> changes as
> > > well.
> > > 
> > > For key generation support I think we should provide support for 
> the
> > > following:
> > > 
> > > 1.  Sequences - like the OracleSequenceMaxValueIncrementer.  Do we 
> need
> > > something for Postgres and DB2?
> > > 
> > > 2.  Identity/Autoincrement - a "sequence" table where we use some 
> sql to
> > > increment and retrieve the next value.  This is implemented in
> > > MySQLMaxValueIncrementer.  Do we need implementations for HSQL, MS 
> SQL
> > > Server, DB2 and Sybase?
> > > 
> > > 3.  Stored Procedure = a procedure that wraps access to a Sequence,
> > > Identity/Autoincrement or any other proprietary database key 
> generation
> > > facility.  I'll look into providing an implementation for this.
> > > 
> > > I think we should discourage use of "select max(id) + 1" type of
> > > solutions and therefore we should remove the 
> RdbmsMaxValueIncrementer. 
> > > We can leave this type of implementation up to the individual 
> developer.
> > > 
> > > Thomas
> > > 
> > > > This is a multi-part message in MIME format.
> > > > 
> > > > 
> > > > Hi Isabelle,
> > > > 
> > > > Related on my last post on the Spring Framework list, I enclosed 
> my
> > > > proposals of changes to handle long keys on databases.
> > > > As I'm not registered as developer, I cannot upload. And in all 
> cases,
> > > > it's your work, so your approval is also mandatory.
> > > > 
> > > > NB: It's nothing about caching in this proposal.
> > > > 
> > > > Best regards,
> > > > Jean-Pierre PAWLAK
> > > > jp....@ti...
> > > >  
> > > 
> > > 
> > > 
> > > -------------------------------------------------------
> > > 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
> > 
> > 
> 
> 
> > Jean-Pierre,
> > 
> > Thanks for your changes.  I think adding long as a return value has 
> been
> >  planned, but it was never implemented.  Isabelle, do you you want to
> > make these changes or do you want me to do it?  I'm modifying a few
> > other jdbc classes this weekend, so I don't mind adding these 
> changes as
> > well.
> > 
> > For key generation support I think we should provide support for the
> > following:
> > 
> > 1.  Sequences - like the OracleSequenceMaxValueIncrementer.  Do we 
> need
> > something for Postgres and DB2?
> > 
> > 2.  Identity/Autoincrement - a "sequence" table where we use some 
> sql to
> > increment and retrieve the next value.  This is implemented in
> > MySQLMaxValueIncrementer.  Do we need implementations for HSQL, MS 
> SQL
> > Server, DB2 and Sybase?
> > 
> > 3.  Stored Procedure = a procedure that wraps access to a Sequence,
> > Identity/Autoincrement or any other proprietary database key 
> generation
> > facility.  I'll look into providing an implementation for this.
> > 
> > I think we should discourage use of "select max(id) + 1" type of
> > solutions and therefore we should remove the 
> RdbmsMaxValueIncrementer. 
> > We can leave this type of implementation up to the individual 
> developer.
> > 
> > Thomas
> > 
> > > This is a multi-part message in MIME format.
> > > 
> > > 
> > > Hi Isabelle,
> > > 
> > > Related on my last post on the Spring Framework list, I enclosed my
> > > proposals of changes to handle long keys on databases.
> > > As I'm not registered as developer, I cannot upload. And in all 
> cases,
> > > it's your work, so your approval is also mandatory.
> > > 
> > > NB: It's nothing about caching in this proposal.
> > > 
> > > Best regards,
> > > Jean-Pierre PAWLAK
> > > jp....@ti...
> > >  
> > 
> > 
> > 
> > -------------------------------------------------------
> > 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
> > 
> > 
> 
> -- 
> Thomas Risberg
> tri...@tr...
> 
> 
> -------------------------------------------------------
> 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