Object design question: Object with linked display


I have a table design from a previous project that I am trying to bring over to Aurelius.
The table links back to the customer table (object)

   ID                Integer
   ...othe fields....
   ContactID    Integer

Under the previous design, we were pulling the Link table and a read-only contact name in with the query and using an update SQL query to post only the link table fields. Think of it as a semi updatable view. When adding rows, the contact name would be grabbed and inserted into the Display field which was a non-updateable field.

If I redesign the link table to an object that has a customer as an association

    [Association([TAssociationProp.Lazy], [])]
    [JoinColumn('CONTACT_ID', [])]
    FLinkContact: Proxy<TContact>;

then it will load the entire TContact into just to get the name which I need for display purposes...

I'm trying to reduce the size of the returning datasets.

Had thought that I might be able to add a field property that grabs the name from the ID, and sticks it in the display field. but that would cause a lot of smaller calls back to the server, rather than grabbing those fields the first time.

Is there a way so I can just retrieve the LinkObject(s) and the Contact display name and have it (the link object/table) still editable??



Hello John,

For retrieving just the DisplayName you could create an entity class like TDisplayContact which will have declared just the properties you want to retrieve. But I don't understand what you want to edit. You said DisplayName is a non-updatable field, so what exactly you want to modify?


The only thing we ever updated when creating a new record or modifying an existing was to change the ContactID field. We were using a TClientDataSet and set the provider flag on the Display name had pfInUpdate as False. That way if we got the value in from the lookup query and if we changed the ContactID and then changed the field for display to the user to the new name,  it wasn't part of the update as it went back (as it wasn't required). I'm sure that's not the cleanest way to do that using the older CDS/DataSnap model but it worked.

So the TDisplayContact class is that an ancestor class for the TContact (which you would then use single table inheritance) or as a separate class which also maps to the contact table in the DB. Can you have more than one entity mapping to the same physical DB table?


The update mechanism is a different beast. Aurelius holds the modifications per object. If you change the Contact property (the object reference), it will update the foreign key in the database. That doesn't mean it will update the Display name, since it was not modified in the Contact object.

TDisplayContact would be a different class (not inherited). You can have multiple classes for same table, but be careful when updating/building the database, or it will raise an error. It's best that you organize your mapping into models using the multimodel design: https://www.tmssoftware.biz/business/aurelius/doc/web/multi-model_design.html