What an interesting coincidence. I just hit this issue myself in upgrading to RC1. Our schema has a multitude of conditional foreign keys and the change to primitive key types is causing me much grief. What really is causing the problem though is the buildCriteria() method. It simply adds all columns to the criteria whenever it is saved (which puts a 0 into a field instead of null and ends up where your problem is). Can anyone explain why it does this instead of using only the necessary subset?
We've worked around some polymorphism issues with the statics in BasePeer (see the recent thread "reasoning behind so many static methods in BasePeer") and one of the things we did in an intermediate layer was to dynamically build a Criteria by adding to it as setters are called on the OM object. What that allows me to do now (and what I am really, really considering) is to tweak the base peer class and change buildCriteria() to simply grab my object's dynamically maintained Criteria object instead of slamming every column in. Overall this solution seems a little cleaner than this patch (although I freely admit that my cursory examination of the patch still leaves me far from fully groking it). walt -----Original Message----- From: Will Holcomb [mailto:will@;himinbi.org] Sent: Sunday, November 10, 2002 6:08 PM To: Will Holcomb Cc: [EMAIL PROTECTED] Subject: [SOURCE] Issue #TRQS63 - fixes problem with null keys in rc2 You can view the issue detail at the following URL: <http://nagoya.apache.org/scarab/issues/id/TRQS63> Type : Patch Issue Id : TRQS63 Reported by: Will Holcomb wholcomb - ([EMAIL PROTECTED]) Details: Platform: All Operating system: Redhat Summary: fixes problem with null keys in rc2 Description: RC2 switches how keys are maintained. Before they were returned as subclasses of ObjectKey, but they are now maintained as the primitive type of the column. This raises an issue in that representing a null field is possible with a null key, but there is no analogue for null for an int. I have two tables which are optionally joined and the foreign key may be null. When save is called it is setting the field to 0 (an uninitialized int) rather than properly setting it to null. The attached path covers: Changes the template for the generated peer to: 1. Add public final static int COLUMN_X_INDEX which has the index in the schema of the particular column 2. Adds an isSet check for each column in buildCriteria Changes the template for the generated class to: 1. Add boolean[] isSet with an entry for each column 2. Add isSet = true to the setter for each column 3. Add isSet(int) and isSet(String) boolean methods to check if column is set by index or name 4. Changes getByPosition to remove redundant numbering Changes default.properties: 1. Adds torque.indexPostfix to control what is appended to column name to get index field This patch also adds a singleton to the genertated peer and static method to access it as well as altering generated class to use this method in getPeer. This allows access to a singleton for a peer without making getPeer static. This is part of fixing the inheritance issues without affecting exiting methods too much. I started on this before discovering that the null fields were broken. Status: Unconfirmed Priority: Medium Vote: High Functional area: UI -- To unsubscribe, e-mail: <mailto:turbine-torque-dev-unsubscribe@;jakarta.apache.org> For additional commands, e-mail: <mailto:turbine-torque-dev-help@;jakarta.apache.org> -- To unsubscribe, e-mail: <mailto:turbine-torque-dev-unsubscribe@;jakarta.apache.org> For additional commands, e-mail: <mailto:turbine-torque-dev-help@;jakarta.apache.org>
