Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Wrong changes in the change history #138

Open
032660 opened this issue Nov 25, 2024 · 8 comments
Open

Wrong changes in the change history #138

032660 opened this issue Nov 25, 2024 · 8 comments

Comments

@032660
Copy link

032660 commented Nov 25, 2024

Hello colleagues!

We are working on the project https://github.tools.sap/erp4sme/crypto-for-business.

The issues that we have are referring to the change tracking; however the difference to be reflected in the change history is being estimated in the utilities of node_modules/@sap/cds/libx/_runtime/common/utils.

We have an app:

App annotation app\payment\downstreamPaymentProcessors\annotations.cds
Entity CDS db\payment\paymentRails\DownstreamPaymentProcessors.cds
UI service CDS srv\payment\paymentRails\ui-service-downstreamPaymentProcessors.cds
UI service provider srv\payment\paymentRails\ui-service-downstreamPaymentProcessors.ts

Entity DownstreamPaymentProcessors has compositions to two views:

entity DownstreamPaymentProcessors : cuid, managed {
@changelog
@title : '{i18n>Name}'
name : String;

@title    : '{i18n>Integration}'
@changelog: [Integration.name]
Integration            : Association to one Integrations;

@title    : '{i18n>ActivationStatus}'
@changelog: [ActivationStatus.name]
ActivationStatus       : Association to one codelists.PaymentProcessorActivationStatusCodes;
callbackSupported      : Boolean;
NetworkMappings        : Composition of many DownstreamPaymentProcessorNetworkMappings
                             on NetworkMappings.contextObjectId = $self.ID;
CryptocurrencyMappings : Composition of many DownstreamPaymentProcessorCryptocurrencyMappings
                             on CryptocurrencyMappings.contextObjectId = $self.ID;

}
entity DownstreamPaymentProcessorNetworkMappings as
select from GeneralMappings {
*,
Network : Association to one Networks on Network.ID = sourceObjectId,
}
where
contextEntityType.code = 'PAYMENT_PROCESSOR'
and sourceEntityType.code = 'NETWORK';

entity DownstreamPaymentProcessorCryptocurrencyMappings as
select from GeneralMappings {
*,
Cryptocurrency : Association to one Cryptocurrencies on Cryptocurrency.ID = sourceObjectId,
}
where
contextEntityType.code = 'PAYMENT_PROCESSOR'
and sourceEntityType.code = 'CRYPTOCURRENCY';

These Mappings entities are also annotated for change tracking.

Although UI service entity is declared as draft enabled, all DB operations during SAVE event are fulfilled explicitly via wrapper service (srv\payment\wrapper\wrapper-service.cds).

  1. The issue with the change history is:

Whenever a UI change is done on mappings (for example a new mapping is added) then the mappings which have existed so far are shown as if they were deleted (although they are not):

image

I saw:
In node_modules/@sap/cds/libx/_runtime/common/utils/comparejason.js the function _addToBeDeletedEntriesToResult set _op: 'delete' on the mappings.


  1. I tested also an alternative way and removed calling DB operations during SAVE – i.e. let drafts to be activated per standard draft handling (I did it in the branch mappings-change-history).
    Then I saw that unlike the previous solution node_modules/@sap/cds/libx/_runtime/common/utils/comparejason.js did not get any old value to compare with the new one. Then mappings were marked with _op: 'create' – as if they were new.

image


  1. Additional issue:
    For the entity DownstreamPaymentProcessor some fields are shown as updated in every change log, although they were not changed:

image

Could you please help? We think that the issues began after upgrading the CDS version to CDS8 (we have 8.4.2 now).
Kind regards,
Elena Gurevitch

@nkaputnik
Copy link
Contributor

@Sv7enNowitzki is this related to the DATE-Issues with the DB driver that we have?

@Sv7enNowitzki
Copy link
Collaborator

@Sv7enNowitzki is this related to the DATE-Issues with the DB driver that we have?

Regarding the third issue mentioned in the ticket, I suspect it might be the case, as it seems that C4B has started using the new driver @cap-js/hana after upgrading to cds8

Best Regards,
Wenjun

@032660
Copy link
Author

032660 commented Nov 27, 2024

We are watching different behavior of the change history also in other apps. I have an impression, evrything due to upgrade.

For example in two apps no any "create" changes are shown at all, only "update" - the entities were created via wrapper service and updated also via wrapper service, but within job execution.

Earlier (before upgrade, in the previous release) we had issues with missing change entries for job execution. Then they were solved.

Now it is somehow vice versa.

Kind regards,
Elena

@032660
Copy link
Author

032660 commented Nov 29, 2024

Hello colleagues,

I found an additional issue. In some apps "create" changes are not shown.

I found even the reason. For example, for the "Wallets" app:


Change history is being written on "before CREATE" event. Wallet is created per action; INSERT is executed with ID = null).
So at the time when change history should be written there is no any entity ID - that is the reason.
If we create UUID for example in UI service and send it in the request then it will work.


However it would be rather a workaroud because an entity can be created without ID and ID is being generated during INSERT.

The questions are:

  1. Why changelog is being inserted on "before" event?
  2. How is it possible that the same used to work before upgrading CDS and Hana DB?

Kind regards,
Elena

@032660
Copy link
Author

032660 commented Dec 2, 2024

P.S. As I also supposed, before upgrade ID was filled on "before CREATE" event.

Could you please test the same?

@032660
Copy link
Author

032660 commented Dec 3, 2024

@Sv7enNowitzki , @nkaputnik , Colleagues!

Could you please check?

@nkaputnik
Copy link
Contributor

The questions are:

  1. Why changelog is being inserted on "before" event?
  2. How is it possible that the same used to work before upgrading CDS and Hana DB?

Kind regards, Elena

Hello Elena,
I can only guess that it's to do with the new DB drivers that were introduced with CDS 8.
I will need to do a much deeper digging, and a fix won't be straightforward, so the best thing we could do right now would be to document the limitation and workaround in the readme for the time being.

Best,
Nick

@032660
Copy link
Author

032660 commented Dec 17, 2024

Hi Nick,

The only workaround I found was to generate an ID and fill it before inserting an entry.

Kind regards,
Elena

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants