How can we build a KUIB app that maintains a temp-table rather than a database table? - Forum - Kendo UI Builder - Progress Community

How can we build a KUIB app that maintains a temp-table rather than a database table?

 Forum

How can we build a KUIB app that maintains a temp-table rather than a database table?

This question is answered

Hi,

We want to build a KUIB CRUD app that maintains data that is in a "location" temp-table at the back end (persisted in a location.json file rather than in a location database table). We believe we have the following defined correctly in the locationBE.cls:

* location (this is the TT table that we want to update instead of a database table)

* Data-source srclocation for location.

* define temp-table ttlocation before-table bttlocation (this is the TT that is used by the service and KUIB app)

When the locationBE.cls is instantiated, it does a read-json from the location.json file to load data into the location temp-table. When an update, create or delete operation occurs, we want to process it as usual at the back end (where the data in the location temp-table would be updated from the ttlocation), but add a step at the end of the update/create/delete process to refresh the location.json file with the new data. This technique is useful during early development when table schemas are not fully developed, especially for small control or config tables that are meant to be maintained by one person at a time. (We want to quickly build an actual UI to maintain this data rather than maintain it by editing the location.json directly). Later, the table info is moved to a database for general deployment.

We are able to successfully see the catalog and the ttlocation data rows in a web browser. However, when attempting to use this data in the KUIB app, the attached "JDSO: autoApplyChanges is not supported for saveChanges(true) with a temp-table. Use jsdo.autoApplyChanges = false" error is returned.

* Is it possible to build a KUIB app that maintains a temp table at the back-end?

* How can we set the jsdo.autoApplyChanges = false and what are the implications of doing so?

* For a one-table temp-table maintenance program, should the BE support CRUD only instead of CRUD and Submit?

Thank you.

Regards,

Carl

Verified Answer
  • Hi Carl,

    A temp-table BE is supported, but with CRUD support only and no Submit. So you should not be calling the jsdo.saveChanges(true) method, but rather jsdo.saveChanges(false).

    So it sounds like you have implemented a Submit operation in your backend for you temp-table BE? If so, this is causing the issue.

    We do not support the Submit operation for temp-tables only, because in order for it to work correctly in all cases, we require the before-image data support.

    If you want to support Submit functionality for a tt BusinessEntity, you would have to implement it via a customized invoke operation.

    Maura

All Replies
  • Hi Carl,

    A temp-table BE is supported, but with CRUD support only and no Submit. So you should not be calling the jsdo.saveChanges(true) method, but rather jsdo.saveChanges(false).

    So it sounds like you have implemented a Submit operation in your backend for you temp-table BE? If so, this is causing the issue.

    We do not support the Submit operation for temp-tables only, because in order for it to work correctly in all cases, we require the before-image data support.

    If you want to support Submit functionality for a tt BusinessEntity, you would have to implement it via a customized invoke operation.

    Maura

  • Hi Maura,

    Thanks for clarifying the use of CRUD with temp-table BEs.

    We were attempting to do this with Submit and doing just CRUD works well to update a TT at the back-end.

    Carl