DOM – storing a lengthy string in on-prem vs StaaS storage

Solved479 viewsDOM low-code
3
0 Comments

Hi all,

On a low-code app, I have a page which provides an overview of sites. This is achieved by using the grid components, which is showing some static and real-time site information including also a picture. In order to easily display the corresponding site picture, this is saved as base64 code into the corresponding site DOM section, so as metadata to the site.

When using StaaS, I seem to be able to easily store this base64 code in DOM, which is of course quite lengthy. However, when doing the same on a machine that is connected to on-prem storage, it seems to fail when trying to save the record in DOM.

Although not certain, I assume that it is related to the StaaS and on-prem storage. Are there any limitations on the length of a string, and is that any different from StaaS compared to on-prem storage? If not, what is the best way to see why a DOM Insert through low-code app would be failing through a form?

Thanks,

Leander Druwel [SLC] [DevOps Advocate] Selected answer as best 3rd June 2024

1 Answer

6
4.52K 1 Comment

Hi Leander,

As you have noticed, there is indeed a limitation on the length of a DOM field when using Elasticsearch or OpenSearch. Due to the way the data is indexed for search, the limit is 32,766 UTF8 bytes. If characters in the string require multiple UTF8 bytes, the max amount of characters will then be lower than 32,766. Unfortunately, there is no clear error indicating this at the moment, but a task is underway to fix this (DCP238096). It seems that the STaaS storage option does support much larger values, however, we would recommend keeping the data inside a DOM instance as small as possible. You could try storing a reference to an image on disk instead of storing the full image in the instance.

Thomas Ghysbrecht [SLC] [DevOps Enabler] Edited answer 3rd June 2024
Leander Druwel [SLC] [DevOps Advocate] commented

Thanks Thomas! Meanwhile, I did find the possibility to also host the images in a public folder, which is remotely accessible through dataminer.services

https://docs.dataminer.services/user-guide/Cloud_Platform/RemoteAccess/Cloud_Remote_Access.html?q=remoteaccess

So, conclusion is that DOM is the right place to store all metadata linked to the sites in this case. But storing a path to the image is surely the preference here.