Localized & draft & ID_texts #677
Conversation
Document current behavior, reasoning, potential way forward ...
![github-actions[bot]](https://avatars.githubusercontent.com/in/15368?s=60&v=4){kind=small}
There was a problem hiding this comment.
Spelling Mistakes
- ./advanced/fiori.md:497:77 Unknown word "redeploment"
Generally, for each spelling mistake there are 2 ways to fix it:
- Fix the spelling mistake and commit it.
- The word is incorrectly reported as misspelled → put the word on the project-words.txt list, located in the root project directory.
Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>
|
@David-Kunz @beckermarc - as discussed in spec meeting on Monday: please add whatever you think is helpful, in particular w.r.t. runtime and Fiori. |
advanced/fiori.md
Outdated
| Today Fiori can also deal with composite keys with non-UUID types. For an entity with such a key, | ||
| Fiori cannot generate an initial value. So when creating a new entry, a pop-up is launched asking | ||
| the user to provide the key values. |
There was a problem hiding this comment.
I would rather say that the backend doesn't allow key changes, hence Fiori Elements shows a popup to set the value once and doesn't allow to modify the value afterwards.
There was a problem hiding this comment.
please add that to the text / change the text accordingly
|
@David-Kunz @beckermarc - little reminder - as discussed in spec meeting last week: please add whatever you think is helpful, in particular w.r.t. runtime and Fiori. |
advanced/fiori.md
Outdated
| on by also adding the annotation `@fiori.draft.enabled` to the main entity. | ||
| This annotation does however not only include the `.texts` entity into the draft tree, but it also | ||
| changes the key of the `.texts`entity. | ||
| At the time draft support was implemented in CAP, Fiori required (TODO is this true?) |
| Fiori cannot generate an initial value. So when creating a new entry, a pop-up is launched asking | ||
| the user to provide the key values. | ||
|
|
||
| Is there a way to avoid this popup, but on the other hand keep the structure of the `.texts` entity |
There was a problem hiding this comment.
it is possible via annotation to suppress the popup (don't ask me what it is). node backend generates values for all uuid key properties, regardless how many. so it might be possible to just prompt the user for the locale info...
There was a problem hiding this comment.
I'm not sure if it's possible to suppress the pop up for non-UUID keys. It's something, the user cannot change, even in draft mode, hence the moment the user 'hops out' of the field, it would need to become immutable - Fiori elements can't do that.
| Is there a way to avoid this popup, but on the other hand keep the structure of the `.texts` entity | ||
| and table unchanged? | ||
|
|
||
| The basic idea is to have in the CDS runtime and for the database a `.texts` entity and table with |
There was a problem hiding this comment.
so it would be the following?
CREATE TABLE S_Books_texts (
locale NVARCHAR(14) NOT NULL,
ID INTEGER NOT NULL,
title NVARCHAR(255),
PRIMARY KEY(ID, locale)
);
| Is there a way to avoid this popup, but on the other hand keep the structure of the `.texts` entity | ||
| and table unchanged? | ||
|
|
||
| The basic idea is to have in the CDS runtime and for the database a `.texts` entity and table with |
| This only works, however, if we can guarantee that Fiori never sends a query based on `ID_texts`. | ||
| So, an ObjectPage for a text entry would not work. | ||
|
|
||
|
|
There was a problem hiding this comment.
issue: when creating the new instance, we need to generate the id in the backend. at that point, however, we don't yet know the intended locale -> anything that tries to concatenate a fake id field on read (e.g., ID + '_' + locale as ID_texts) is doomed.
There was a problem hiding this comment.
anything that tries to concatenate a fake id field on read (e.g., ID + '_' + locale as ID_texts) is doomed.
Not during runtime, only when doing the CSV import, so it should be fine.
There was a problem hiding this comment.
In CAP Java CSVs are also uploaded by the runtime (in case of in-memory DBs). We chould have a well-defined hashing algorithm, which is used accross the runtimes.
Co-authored-by: Adrian Görler <[email protected]>
| At the time draft support was implemented in CAP, Fiori required | ||
| that a draft enabled entity must have a single key element of type UUID. | ||
| As a `.texts` entity by construction has at least two key elements (the `locale` plus the key elements | ||
| of the main entity), we remove the `key` property from all these elements and add a technical key element | ||
| `ID_texts` of type UUID. |
There was a problem hiding this comment.
I thought the motivation to introduce ID_texts was to allow to change the locale of an inactive draft which would not be possible if the locale was part of the key. Otherwise I don't think the compound key would be an issue.
@beckermarc - correct me if I'm wrong.
There was a problem hiding this comment.
Yes this was the reason. Draft itself worked with keys locale plus the original keys, but the problem was that the locale had to be given at creation time of the new text and couldn't be changed anymore afterwards. This was undesirable from UX perspective.
| Deployment (for PostgreSQL) has recently been improved to handle this. For each entry, the values of | ||
| the original key elements are used to generate a hash value which is then used as value for | ||
| `ID_texts`. It is important the the generated value is stable, so that upon redeployment the same values | ||
| for `ID_texts` are produced. |
There was a problem hiding this comment.
I was not aware of this. I assume that the generated hash value adheres to the UUID format.
Maybe we could invent an @cds.on.insert-variant to express that a hash should be computed from the data upon insert.
| This only works, however, if we can guarantee that Fiori never sends a query based on `ID_texts`. | ||
| So, an ObjectPage for a text entry would not work. | ||
|
|
||
|
|
There was a problem hiding this comment.
In CAP Java CSVs are also uploaded by the runtime (in case of in-memory DBs). We chould have a well-defined hashing algorithm, which is used accross the runtimes.
| @@ -425,6 +425,97 @@ Adding the annotation `@fiori.draft.enabled` won't work if the corresponding `_t | |||
|
|
|||
| If you're editing data in multiple languages, the _General_ tab in the example above is reserved for the default language (often "en"). Any change to other languages has to be done in the _Translations_ tab, where a corresponding language can be chosen from a drop-down menu as illustrated above. This also applies if you use the URL parameter `sap-language` on the draft page. | |||
|
|
|||
| #### Background | |||
|
|
|||
| > TODO: find a good place for this section, maybe make it internal | |||
There was a problem hiding this comment.
We could also add a link from here: https://pages.github.tools.sap/cap/docs/guides/localized-data#behind-the-scenes
Document current behavior, reasoning, potential way forward ...