the short term work-around is to set javaType="object" for your primary key fields, and use the object types for primary keys. This will allow your app to work, and should be no more troublesome than using ObjectKey variants - using Integer rather than NumberKey would require a similar conversion (ie Integer.intValue() instead of NumberKey.intValue().. which prior to this change would have been NumberKey.getBigDecimal().intValue())
however, longer term is one of the reasons I created TRQ46... > -----Original Message----- > From: Martin Poeschl [mailto:[EMAIL PROTECTED]] > Sent: Friday, October 11, 2002 3:19 AM > To: [EMAIL PROTECTED] > Subject: problems after Key->type change (TRQ41) > > > after the change described in TRQ41 (make getPrimaryKey > return ObjectKey but getPkField return the > type it is) it is not possible to set FKs to null .. which > breaks some of my apps :-( > > there are several ways to fix this: > > a always use Objekt types for the internal representation (as > in TRQ46) > > b always use Objekt types (also for getters and setters) > this would break everything, but we don't need the > setNull(), isNull() methods > > c use the Key types for internal representation of PKs and FKs > > d revert the change > > > in case a and c we should add getters and setters using the > Object type > > 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) > > > comments? > > martin > > > > > > -- > 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]>
