Wrong hdbtabledata for Draft-enabled localized entities

[wattnu]

My deployments to HANA are failing for localized entities which are Fiori draft enabled. For Fiori drafts, the compiler generates an additional key column for the _texts-tables (e.g.. ID_TEXT as UUID). This key column is not part of my csv-File (had no idea before that this column exist and what to put in there).

Deploying to SQLite works well. There, this key column gets filled automatically with a UUID.

Deploying to HANA fails however, because this artificial key is not considered at all.

Regards

[chgeo]

Hey Klaus :)

yes, I see where the issue is.. in order to avoid it, one must explicitly include the ID_TEXT column in the csv. This should work, right? However, as you pointed out, this column is artificial and users maybe should not be concerned with it. What about this idea: in the generated hdbtabledata, we could compute/infer ID_TEXT out of the given key values (Books.ID) and add it as constant value in the hdbtabledata file? Of course only if ID_TEXT is not in the csv.

[wattnu]

Hi Christian, Yes. I think this would meet user expectations that this "secret" column is automatically created for hdbtabledata the same way as it is generated for the database tables. But of course only in case of draft ;(. Thanks and regards,

[chgeo]

What about this idea: in the generated hdbtabledata, we could compute/infer ID_TEXT out of the given key values (Books.ID) and add it as constant value in the hdbtabledata file?

Thinking about it, this can't be done within hdbtabledata, because you can only have a constant value for the whole column there, not for each record. So.. this leaves us with augmenting the csv file copy by the additional column...

[wattnu]

It works fine for SQLite deployment. There, ID_texts gets populated with some generated UUIDs ... Yes, it seems that this requires to not copy the orignal csv into gen/, but a modified one ...