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?