Table map extensions

Requesting add a field or method extension capability to existing table maps

Problem statement

We have received requests to provide platform support for adding a field or method to table maps through extensions.

Adding a field or a method to an existing table map, however, presents some challenges which can lead to unforeseen runtime errors. The reason being that the party adding the field does not have control over all the tables which implement mapping to the table map. The same is true for adding a method to a table map, if the method is called directly as an instance method on the table map.

One of the issues with table maps, is that it is not enforced, that fields on table maps are mapped to fields on all tables implementing the table map. Likewise, another issue is, that it is not enforced, that methods on the table map are implemented as methods on all tables implementing the table map.

The below diagram is meant to illustrate the issue. The diagram shows the SalesPurchTable table map which is implemented by the SalesTable, PurchTable, and SalesBasket tables in the ApplicationSuite model. In addition, an ISV1Header table being part of an ISVModule1 model is implementing the SalesPurchTable table map.

Assume that a new field named AccountingGroupId and a new method named validateAccountingGroup are added to the table map. As the change is made in the ApplicationSuite model, then the tables known to be implementing the table map can be fixed, and get the field and method added as well.

The ISV1Header table in the ISVModule1 model is, however, outside of the control of engineer making the changes to the ApplicationSuite model.

Logic implemented in the ApplicationSuite model, that query the value of a the AccountingGroupId table map field will result in a runtime error, if the table map record is of type ISV1Header.

SalesPurchTable headerTable;
if (headerTable.AccountingGroupId)

Also logic in the ApplicationSuite model, calling the validateAccountingGroup table map method will result in a runtime error, if the table map record is of type ISV1Header.

SalesPurchTable headerTable;
if (headerTable.validateAccountingGroup())

Until the time, when the ISV1Header table has added mapping to the AccountingGroupId field and added the validateAccountingGroup method, then the combined solution is essentially broken.

If we played with the thought of adding the ability to add fields or methods to table maps through extension, the issues above are not being mitigated. Instead they remain the same.

This is illustrated in the next diagram where the ISVModule2 includes extensions of the table map and the implementing tables in the ApplicationSuite model.

The engineer implementing the ISVModule2 has no control over the ISV1Header table in the ISVModule1 model, and therefore the ISV1Header table is still lacking a mapping of the AccountingGroupId field and implementation of the validateAccountingGroup method.

If the compiler enforced, that all fields on table map had to be mapped on all tables implementing the table map, and enforced that methods added to a table map had to be implemented on all tables as well, then the issues would be somewhat the same.

Instead of receiving runtime errors, then adding a field or a method would be a clear breaking change, as tables not having a new field mapped or a new method implemented would result in a compile when the model containing the added field/method is applied.

Because of the issues described and the lack of ability to control which tables implement the table map, then we have taken a route of refactoring the usage of the table maps into a model, which allows extending with solution with additional fields and methods.


Extending table maps used as interfaces

Extending table maps used for versioning


Comments (4)

  1. kl says:

    1. how did you create the SalesPurchaseTable.ISV2Extension from SalesPurchTable? When I try to right click SalesPurchTable and try to create a extension, nothing happens.

    2. How did you add the method validateAccountingGroup() in the ISV2 table extensions? You can’t add methods in extension tables, you can only copy event handlers.

    I am not seeing how you did this without using any of overlayering code, please help!!

    1. Hi kl.
      This page is meant to describe, the reason why we do not providing the above capabilities, because the capabilities could lead to functional or runtime errors.
      We have currently identified two different patterns for how it is possible to refactor customizations to table maps, and these are described as ‘Extend table maps used as interfaces’ and ‘Extend table maps used for versioning’.
      Also see

  2. Ali Adamu says:

    Hello Michael. Great explanation!
    I’d only point out that you probably should change “ISV2Header” with “ISV1Header” according with the image below the sentence. Just to avoid any misunderstanding. Am I wrong?

    1. Thanks Ali – you are absolutely right. I’ve updated the text to avoid further misunderstandings.

Skip to main content