Hello, We are building a set of CDTs and we have the following case.

Hello,

We are building a set of CDTs and we have the following case.

We have defined a CDT "xChild" that is a child of two different CDTs "xParent1" and "xParent2" which are all under a main CDT "xParentMain".
When we verify the Data Store in which these CDTs are placed, an SQL DDL is generated in which the table of "xChild" has one foreign key column for "xParent1" and TWO foreign key columns for "xParent2".

How does the Data Store generate the foreign key columns that show up in the database?

I ask this because in the Data Store we originally had all the above CDTs and that's how the above issue appeared.
We have even tried to only include "xParentMain" and "xParent2", which had the same result.

However, when we only had "xParentMain" in the Data Store OR "xParent1" and "xParentMain", then the generated SQL DDL did NOT have two foreign key columns for "xParent2".

We need to understand this behavior and what could cause this based on the defi...

OriginalPostID-150061

OriginalPostID-150061

  Discussion posts and replies are publicly visible

Parents
  • I have attached the XSDs of all the CDTs in the graph tree. The problem we are facing with the foreign key columns is in the database table of the CDT MA_PricingExceptions.

    This is the structure of the graph tree of these CDTs:
    MA_InterestInstalations
    ->MA_Solutions(Array)
    ->MA_ePos_Pricing
    ->MA_PricingExceptions(Array)
    ->MA_POS_Pricing
    ->MA_PricingExceptions(Array)

    Today, we made changes to the MA_PricingExceptions, MA_ePos_Pricing and MA_POS_Pricing CDTs where we simply added an extra field in each of the 3 CDTs. After we executed the Impact Analysis on all these and all references were updated throughout the application, the Data Store would NOT be verified eventhough the added fields were added to the database tables. The reason the Data Store can not be verified is because it is adding an extra foreign key column to the MA_PricingExceptions table pointing to the MA_ePos_Pricing table. The MA_PricingExceptions table already has a foreign key column pointing to the MA_ePos_Pricing table.

    I would like to know the logic behind creating foreign key columns from a CDT graph because in this case i fear that every time a change is made the Data Store will not be verified for the reason i described above.

    As a note, the structure of the CDT graph, in terms of its relationships has not changed since Friday when I first posted this issue of ours.

    MA_InterestInstalations.xsd

    MA_Solutions.xsd

    MA_ePos_Pricing.xsd

    MA_POS_Pricing.xsd

    MA_PricingExceptions.xsd

Reply
  • I have attached the XSDs of all the CDTs in the graph tree. The problem we are facing with the foreign key columns is in the database table of the CDT MA_PricingExceptions.

    This is the structure of the graph tree of these CDTs:
    MA_InterestInstalations
    ->MA_Solutions(Array)
    ->MA_ePos_Pricing
    ->MA_PricingExceptions(Array)
    ->MA_POS_Pricing
    ->MA_PricingExceptions(Array)

    Today, we made changes to the MA_PricingExceptions, MA_ePos_Pricing and MA_POS_Pricing CDTs where we simply added an extra field in each of the 3 CDTs. After we executed the Impact Analysis on all these and all references were updated throughout the application, the Data Store would NOT be verified eventhough the added fields were added to the database tables. The reason the Data Store can not be verified is because it is adding an extra foreign key column to the MA_PricingExceptions table pointing to the MA_ePos_Pricing table. The MA_PricingExceptions table already has a foreign key column pointing to the MA_ePos_Pricing table.

    I would like to know the logic behind creating foreign key columns from a CDT graph because in this case i fear that every time a change is made the Data Store will not be verified for the reason i described above.

    As a note, the structure of the CDT graph, in terms of its relationships has not changed since Friday when I first posted this issue of ours.

    MA_InterestInstalations.xsd

    MA_Solutions.xsd

    MA_ePos_Pricing.xsd

    MA_POS_Pricing.xsd

    MA_PricingExceptions.xsd

Children
No Data