Could you shed more light on this? I think I just finished changing everything from a NumberKey to an Integer object. And now we are going to change again to int's? That seems like a very drastic change, and I am not sure I see the advantages? I also share the concerns about nulls? If I want to update an object that has a forignkey link to another table, then do I say setForeignKey(0) to make it null? Seems very error prone for me to try and find everyplace I used to do setForeignKey(null) and change it to setForeignKey(0)...
If we need to support int's instead of java objects, shouldn't that be a setting in the templates just like useManagers is? Or is this just a tempest in a teapot :-) Eric Pugh -----Original Message----- From: Russell Edens [mailto:[EMAIL PROTECTED]] Sent: Friday, November 22, 2002 3:26 AM To: '[EMAIL PROTECTED]' Subject: Issues with change of NumberKey to int's in RC2 This is a big heads up. Those who are considering the upgrade should be aware of the significant change to use int's instead of NumberKeys. > -----Original Message----- > From: Russell Edens [mailto:[EMAIL PROTECTED]] > Sent: Friday, November 22, 2002 12:45 AM > To: Will Holcomb > Cc: [EMAIL PROTECTED] > Subject: [SOURCE] Issue #TRQS63 modified > > > Issue TRQS63 has just been modified by user russelle > > You can view the issue detail at the following URL: > <http://scarab.werken.com/scarab/issues/id/TRQS63> > > The following modifications were made to this issue: > > I like the removal of the ObjectKeys in favor of java types...but why > change objects to primitive types? Specifically IntegerKey's to int's? > Why not make them Integer's instead? > > > John's workaround may downgrade this from critical. But this seems like a > workaround to a fundamental issue. An int does not represent null value > without some special values . This change was a huge headache for us ... > so much so we had to bail on RC1. Most of the issues were related to > updates and inserts for foreign keys. We do a fair amount of narrow > updates using the doUpdate(Criteria, Criteria) methods. The other issue > we ran into is the additional coercion into an ObjectKey for int column > key values. This could be change to Object if the key type become > Integer. We would really like to see object types for keys by default. > Then the workaround to use primitives could still be used for the minority > of people that would want it to work that way. I especially don't like > having to compare against 0 for an int to see if it is null. (Not to > mention that some databases will have keys with a value of 0 in them.) > Because we use integers as keys for most of our tables this issue must be > raised. I don't see why most everyone who takes the 3.0 release will have > similar issues and problems. > > Reference Thread: > http://archives.apache.org/eyebrowse/BrowseList?listName=turbine-torque- > [EMAIL PROTECTED]&by=thread&from=241658 > > > > > > -- > To unsubscribe, e-mail: <mailto:turbine-torque-dev- > [EMAIL PROTECTED]> > For additional commands, e-mail: <mailto:turbine-torque-dev- > [EMAIL PROTECTED]> -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
