Hello team,
Lately we have been refactoring our data pool implementation in cosmo by introducing a new strategy that synchronizes data from an A12 application into a data warehouse. This synchronization is made using the updated timestamps in CDM and DM metadata fields (i.e: get A12 documents that were updated in the last hour).
After doing some tests we found that we have a CDM (i.e: ContractCDM) that contains a link to a DM (i.e: PartnerDM):
And if we switch from document A (i.e: Partner X) to document B (i.e: Partner Y) the updatedAt field in metadata structure from the ContractCDM does not change.
That can bring some problems to our new data pool strategy, because A12 interprets that this CDM was not updated, but in fact it was, because we deleted the link to document A and added a link to document B.
Also, in terms of auditory, it won’t be possible to understand who was the person that added/deleted/changed some links and when.
Best regards,
Luís Ferreira
Hey @luis-cached-pond ,
The CDD (the document for the CDM) itself does not have metadata. Only the documents that are persisted in the database have metadata. The CDD is only a “comprehensive view” onto this data.
Therefore, if you change data in a CDM context in your client document (So change the name of the Client from “Neuer Kunde” zu “Bekannter Kunde”), then you would persist this change on the Client document, this document would get a new modifiedAt timestamp. (There is no CDD in the database)
The __meta-Group you find as a Root Group in the CDD belongs to the Root Document, so it is the metadata of this document, not the CDD.
Each Document Model Element in the CDM and consequently each document that is joined into the CDD brings its own meta data and you can access this eg with custom code to find the latest timestamp of those elements.
Hello Felix,
Thanks for you answer. For that case we already implemented the idea of going through each child (DM) and check the modifiedAt. It works pretty well.
However, in this case, I’m changing a link from document A to document B and there are no changes in both. It would be really helpful to at least have some field or structure that indicates that in this CDM, document A changed to document B at some time.
Without knowing it, our data pool will contain inconsistent data when compared to the A12 application, because there it will point to document B, but in the data warehouse will continue to point to document A, since “there are no changes in the CDM”.
Hey Luís,
links currently dont carry metadata. Only the link document does. So as a workaround, you could add a link document and update its metadata everytime a link is changed (with custom code)
Cheers
Felix
Hi Felix,
do you mean this “link document”?
But isn’t this only available for many-to-many relationships? I don’t think it makes sense to introduce such relationships just because we need the metadata information for CDD updates when there is no business requirement for them at all.
Do you know whether it’s planned to extend and provide metadate for CDDs yet?
Kind regards,
Jana
Hey Jana,
yes I mean this one and yes, this should only be used for many-to-many Relationships.
There is no ticket/plan yet to add metadata to links directly, please file a ticket for this with your usecase. Currently, there is no metadata for them available in standard Data Services.
For CDDs, there is no ticket/plan to have all of this metadata (metadata of root+child documents + future metadata of the links) aggregated to an additional metadata for the CDD. Please file a ticket for this with your usecase.
