On Fri, 2002-10-11 at 09:48, Martin Poeschl wrote: > Russell Smyth wrote: > > I would think that javaType="object" causing uncompileable code > > would be an even bigger problem.. one that will effect many people!
I think figuring out what the problem is with setting javaType="object" is important before the release and if this is solved there is a reasonable solution to the problem. Define columns that might be null as object types. Note that in the case of pk's these need to be defined as type object, if there are any foreign keys that are defined as object. > >>>>e.g. if there is a FK CUSTOMER.CUSTOMER_ID you'll get: > >>>> > >>>>int getCustomerId() > >>>>Integer|NumberKey getCustomerIdObject() maybe we find a > >>>>better name .. > >>>>void setCustomerId(int id) > >>>>void setCustomerId(Integer|NumberKey id) > >>>> I do not like this. Either use int or Integer. If Integer makes more sense just use it and if there is some reason you need it as an int create a convenience method getCustomerIdAsInt() or use the Integer.intValue() method. I'm confused as to why people need primitive representations of pk's, I can't think of any math one would want to do with them. They are not supposed to have any business meaning. Not sure if the last setter you show is a typo, but do not overload setters. The main reason for this change to use java.lang types was to be more bean friendly and overloading setters is only going to lead to problems and may be invalid in the latest bean spec. john mcnally -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
