I agree. That would help. It has been pointed out that we can change certain settings in the XML (JavaType) to change this behaviour but what I hope to see is the default changed back to an Object-based scheme.
Oh, another complication this causes: if you have any generic or abstract routines that took ObjectKeys as parameters, you can't just directly change them to Object. It requires some additional work (either multiple overloaded methods or temporary object creation to pass a primitive). This isn't a killer problem but it does add more cruft to the code. -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Friday, November 22, 2002 11:15 AM To: [EMAIL PROTECTED] Subject: RE: Issues with change of NumberKey to int's in RC2 I guess then we need one of the committers who made these changes to explain the reasoning behind these changes. I checked the changes page: http://jakarta.apache.org/turbine/torque/changes.html and did not see anything about this change. If so, what is the recommended strategy. I really would like to hear from one of the committers about the change, just to make sure everyone is up to date... Eric -----Original Message----- From: Walt Armour [mailto:[EMAIL PROTECTED]] Sent: Friday, November 22, 2002 2:18 PM To: 'Turbine Torque Users List' Subject: RE: Issues with change of NumberKey to int's in RC2 Yes, RC1 (and now RC2) incorporated a change that moved key types to either String or int (compared to StringKey and NumberKey previously). It is a drastic change and if you have a large codebase and/or large schema with numerous foreign keys then this will be a painful change to complete (if possible to complete at all, we bailed on it). Where previously we could naturally check for values and nulls we now have to create a fair amount of special purpose code checking for 0 values and performing additional logic when nulls are needed. I still do not fully understand what benefit this change produced but I absolutely understand the pain and detriment this change introduced. Setting a key to 0 doesn't make it null and depending on how the update code is written (by default everything is updated) then it will generate foreign key constraint failures. Any comparisons to null currently (for numeric keys) will need to be against 0 now (a limitation I find distasteful). I wouldn't consider this a tempest in a teapot, it's a serious problem. Of course, if we moved backed to Object-based keys then perhaps we could keep it in the teapot. :) -----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]> -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
