Hello, Just digging up this 2.5 year old thread...
On 18/04/2010, at 4:12 PM, Kieran Kelleher wrote: > Alternative suggestion: > A readonly derived column is another option to expose the PK. The advantage > is that the the new exposed column can be used in standard EOQualifier that > works in memory and for schema-based qualifiers. > > Assuming your primary key col is named "pk" and you want an attribute named > "jobcode" that exposes the "pk"... > > attribute: jobcode > derived: √ > read-only: √ > definition: (pk) [Note: if mapping a column name to a "derived" attribute, > you must surround it in brackets, otherwise EOF cannot parse it] I'm doing this in a model to expose the PK, as described. I have a D2W application that creates a new entity and saves it. Returning to the list page, the derived attribute shows _no value_ (the accessor returns null), even though the saved row is visible in the database, and obviously has a primary key. Logging out and back in does not fix this, though an app restart does—clearly not ideal for production. Is this expected, and thus should I be looking at modelling it some other way? (As an aside, last time I looked at this was a few months ago, and I swear it was behaving properly then—i.e., that the derived attribute was immediately visible.) Or have I more likely botched something? -- Paul Hoadley http://logicsquad.net/
_______________________________________________ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list ([email protected]) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com This email sent to [email protected]
