I'm fairly new to Torque and may not know all the nuances of this change and after generating my <project>-schema.xml a while back I've manually edited it and do all changes that way including setting the javaType for columns but using primitive types by default seems questionable. You just can't handle null values that way. I'd make the Java object numeric types the default and allow the user to override this using javaType when they have concluded that differentiating between 0 and null is unimportant to them or they are not allowing null. If the columns are part of a primary key or are set to disallow null values then you're okay since no null can occur but I'd leave this to the user's discretion and clearly document the trade-offs for object vs. primitive numeric types somewhere.
My 2 cents. -Jamey -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Friday, November 22, 2002 6:37 AM To: [EMAIL PROTECTED] Subject: RE: Issues with change of NumberKey to int's in RC2 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]>
