Would this change also remove the need for torque.overloadKeySetters, which if set to true causes the creation of setters for the key fields and PK using strings. I see two reasons this should no longer be needed: 1 - for String fields it becomes obviously redundant 2 - for non-string fields, you should use the proper types. My guess is that these methods were added to help alleviate the pain caused by using the key types in the first place.
The code as I am working on it will remove this override. Please voice an opinion if you think it should be otherwise, so that I can submit a patch that best fits all! Thank you Russell On Tue, 2002-09-17 at 11:12, J. Russell Smyth wrote: > It has been discussed here (briefly!) the idea of making getPrimaryKey > return ObjectKey, but getIdField methods (for pk fields) return the type > they are. > > The few people who chimed in seemed to be in favor of this, but were > divided on wether this should occur before or after V3-release. There > was a comment that it would be a "breaking change". > > I believe the "breaking" part of it would be to applications, which are > working around the XXXKey type returns through > NumberKey.getBigDecimal().intValue() type conversions. > > This change is critcial to our use of torque, so I am going to have to > implement this change in my copy of torque. I would like to contriubte > this change, of course, assuming it would be accepted. > > My questions are: > A - does anyone have anything to say against this change? > B - does anyone have opinions as to making this a V3 or a V4 change? > C - any other input? > > My main concern is that it seems to be a good change, and I need it, but > I hate to get too far out of sync with the main project. > > Thanks > Russell > > > -- > 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]>
