Problem with CAP localized data

[JuanjoGersol]

Dear experts,

We are facing a problem since a couple of weeks in a service that has been running for almost two years now:

We have two services connected via CDS import where I'm exposing one entity to be used locally from the other service:

@readonly
entity Divisions                as projection on MD.Divisions;

Then I'm doing a basic selection:

 const division = await this.run(SELECT.one.from(this.entities.Divisions)
    .where({ division: t.division_division }));

When the framework expand the selection to build the query changes the * by a list of fields that come from the following structure in the cds.entities.Divisions.elements:

The two highlighted properties are the foreign keys of the automatic association localized. They do not belong to the Divisions entity and I have no idea why they are there.

We have a four systems landscape and we are facing this error in two of the system, I aligned package versions and the problem cannot be reproduced:

I checked for errors in the EDMX file we used on the cds import or in the csn.json file that points to these properties without success.

Can anyone support here?

Thanks,

Juanjo

[patricebender]

>The two highlighted properties are the foreign keys of the automatic association localized. They do not belong to the Divisions entity and I have no idea why they are there.

From the screenshot, it looks like the `texts` composition has no on-condition. Instead it looks like it has the `.keys` property, which essentially makes it a managed association. A managed association always materializes as foreign keys in the entity, where the association is defined. Usually, when you define a `localized` string, the cds-compiler creates an composition named "text" with a proper on-condition: 

entity Foo {
    key ID: Integer;
    description: localized String;
}

the above snippet expands to

// generated by cds-compiler version 4.9.1 
entity Foo {
  key ID : Integer;
  description : localized String;
  texts : Composition of many Foo.texts on texts.ID = ID;
  localized : Association to Foo.texts on localized.ID = ID and localized.locale = $user.locale;
};

@odata.draft.enabled : false
entity Foo.texts {
  key locale : String(14);
  @odata.containment.ignore : true
  key ID : Integer;
  description : String;
};

for me it looks like you are trying to define a `texts` composition by yourself. Please provide a sample repository with detailed steps to reproduce your issue, then I will have a look.

[JuanjoGersol]

Dear Patrice,

Thank you for your comments, you gave me a hint about what could be the problem.

It turns out that when we started the development of this project, two years ago, maybe at an early stage of the CAP framework, and maybe due to our lack of knowledge, we detected that the localized entities were not autoexposed so we exposed then manually in the service.cds of our CAP application:

entity Divisions_texts            as select from MD.Divisions.texts;

 This was done long time ago and has been working without issues until a couple of weeks ago. I think that removing this will fix the issue.

I'll remove and let you know.

Edit: The reason why the entity is exposed manually is that we have a UI application to maintain the translations. For that reason, autoexposed entities that are by default readonly were not valid so we exposed them manually, it seems the way we are doing it is now causing issues. Keep on investigating. Will update if I find the reason. 

Thank you,