Russell Smyth wrote: > 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!
i'm +1 for every solution which makes torque work for me again ;-) i just don't like the setNull() isNull() stuff as described in TRQ46 setter/getter for the Object type would be nicer .. the other way would be to undo the change, release 3.0 and start working on a better solution martin > > >>-----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]> > -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
