Problems when using localized and drafts combined with value helps

[BH91976]

Hi All,

We have a problem with a value help linked to an entity. CAP generates views to retrieve localized data, but seems to look up the data from non-drafts tables instead of the drafts table. Hereby a little more info on what we're experiencing:

So first of all we have the schema.cds:

entity DealHeader:cuid,managed{

    dealNumber: Integer64;

    groupings: Composition of many DealGroupings on groupings.deal = $self;

}

entity DealItems : cuid {

    deal: Association to one DealHeader;

    itemNumber: Integer;

    groupSales: Association to DealGroupings;

}

entity DealGroupings: cuid{

    key code: String(2) @mandatory;

    descr: localized String;

    deal: Association to DealHeader;

}

Then we have the services.cds

DealHeader

        as projection on db.DealHeader {

            *,

            groupings: redirected to DealGroupings

}

entity DealItems as projection on db.DealItems{*,groupSales: redirected to DealGroupings, groupPurchasing:redirected to DealGroupings,groupInvoice: redirected to DealGroupings};

entity DealGroupings as projection on db.DealGroupings{ID,code,descr,texts,deal,localized};  <br>entity DealGroupings_text as projection on db.DealGroupings.texts;

On the fiori we have a list of Groups and we have a value help on item level that is linked to this Grouping. But the strange thing is that it returns nothing, although the entries exist in the drafts tables.When I look at the debugger the join seems to be odd. But I can't seem to influence that. What am I missing or is this a bug. It seems as though the grouping is looking at the localized data not in the drafts table but the actual table, which of course does not have data yet. If you save the header and then edit the items, the valuehelp is filled. But that is obviously not the purpose.

Groups list:

Groups object page:

Item level with valuehelp:

Here is what the call to the database produces:

SELECT count ( 1 ) AS "$count" FROM localized_eu_thevaluechain_trading_shell_srv_DealService_DealGroupings active LEFT JOIN eu_thevaluechain_trading_shell_srv_DealService_DealGroupings_drafts drafts ON active.ID = drafts.ID AND active.code = drafts.code WHERE active.deal_ID = ? [ 'c24be3e6-5af2-4e89-bd56-9e36a2c0cecf' ]
SELECT active.ID, active.code, active.deal_ID, active.descr, ? AS "IsActiveEntity" FROM localized_eu_thevaluechain_trading_shell_srv_DealService_DealGroupings active LEFT JOIN eu_thevaluechain_trading_shell_srv_DealService_DealGroupings_drafts drafts ON active.ID = drafts.ID AND active.code = drafts.code WHERE active.deal_ID = ? ORDER BY active.code COLLATE NOCASE ASC, active.ID COLLATE NOCASE ASC LIMIT 59 OFFSET 0 [ true, 'c24be3e6-5af2-4e89-bd56-9e36a2c0cecf' ]

[vansyckel]

Hi huygen.bert,

Please see Enabling Draft for Localized Data.

Best,
Sebastian

[BH91976]

Sebastian,

Thanks for the reply, but all the base entities do have the

@fiori.draft.enabled.
annotate eu.thevaluechain.trading.shell.db.DealHeader with @fiori.draft.enabled;
annotate eu.thevaluechain.trading.shell.db.DealItems with @fiori.draft.enabled;
annotate eu.thevaluechain.trading.shell.db.DealGroupings with @fiori.draft.enabled;

[vansyckel]

Hi Bert,

In that case, could you please create a support ticket with the entire project/ model and steps how to reproduce?

Your modeling raises some questions for me:

1. Why does DealGroupings have an additional key? Should not be the case when draft-enabled (the compiler outputs a warning with this modeling).
2. DealItems in not part of the draft tree because it is not a composition target of DealGroupings.
3. Why is DealGroupings not a standard projection on db.DealGroupings?
4. Why the redirects?
5. Why do you need entity DealGroupings_text?

You can also check out @capire/fiori as a functioning sample.

Best,
Sebastian

[BH91976]

Sebastian,

1.We removed in my project now the additional keys

2. This is not possible. Because the logic is. We create a header. We create groupings on header level. And we use those groupings on item level. So no create/update of groups is happening on item level. Just linking.

4. Because I have a workarround that has another entity going to the same db.DealGroupings. Where I control the read on the drafts table.

5. Is not really necessary

[vansyckel]

Hi Bert,

Re 2.: I didn't quite get that. But if you follow DealItems.groupSales you will always reach active entities because DealItems and DealGroupings have separate draft trees. Only compositions as fully dependent entities are included in the draft of "business document", associations are not as they are simply related entities.

Best,

Sebastian