I would think that javaType="object" causing uncompileable code would be an even bigger problem.. one that will effect many people!
Not to mention being somewhat important as the primary Torque devs are very resistant to TRQ46 happening before v3 release! > -----Original Message----- > From: Martin Poeschl [mailto:[EMAIL PROTECTED]] > Sent: Friday, October 11, 2002 9:25 AM > To: Turbine Torque Developers List > Subject: Re: problems after Key->type change (TRQ41) > > > Russell Smyth wrote: > > 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... > > i tried the javaType="object" trick, but it doesn't work :-( > > i need it primary for FKs (e.g. an order has an invoice_id > which is null when the order is created) > but this generates uncompileable code .. > i didn't try to fix this, as i thought it would be better to > discuss the possible solutions first .. > > martin > > > > > >>-----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]> > -- 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]>
