Question about XDataClient, Lookup Fields and TObjectMap

BIZ TMS XData
1

I have been struggling with getting lookup fields - in combination with lookup comboboxes - to work properly. On initial loading in a grid, all values were blank until (re-)selected. By chance, I stumbled on the ClientLookup demo and the use of TObjectMap (I had missed this in the What’s New :roll_eyes: ). Applying the TObjectMap, everything works as required now but there’s one thig I’m wondering about.

Assumption: The TXDataClient simply loads entities in TLists' returned (i.e. for data and lookup tables). As such there may be duplicates across the various TLists I have in use for data and lookup.

Question: Let’s assume we have TInvoice and TCustomer. With the TObjectMap in use, I link the lookup reference (TInvoice.Customer) to a lookup TCustomer from the TObjectManager it was added to. In my case, I had TInvoice.Customer defined as Eager. Does this mean, I now have it loaded multiple times and would it not be better/more efficient (faster, less memory) to define it as Lazy to avoid loading it with the TInvoice and with the TCustomer lookup? Thinking even further, with multiple instances of TCustomer loaded across TLists, could it potentially lead to Concurrency (Version) issues?

1 Like
2

I cannot edit any longer, but obviously I meant link to a customer from the ObjectMAP it was added to (not TObjectMANAGER).

3

If you have replace TInvoice.Customer by another (the lookup TCustomer from object map), the previous one is not being used anywhere anymore. Yes, it's in memory just so that it will be destroyed when TXDataClient is destroyed and no memory leaks occur, but you are only effectively using and referencing the new TCustomer instance you used to replace it. So I don't see any problem with that.

4

Hi Wagner,

It's not that it's problem, it's merely a case that I was contemplating if there were duplicates in memory with eager loading. My thinking was that this was avoided by lazy loading (i.e. it's not required to load when accessing as it is already there by linking it).

5

I don't see how lazy-loading would avoid this. It will be the same.