[EDM] Add New Templates with Decorators

[ThuF]

TODO:

• Add support for "precision" and "scale"!

Fixes: #5574

In general, to fix this kind of issue, you add an explicit semicolon at the end of statements that currently depend on JavaScript’s automatic semicolon insertion. This makes the statement boundaries explicit and avoids subtle parsing differences if the code is refactored or minified.

For this specific case, the let projectFile = { ... } declaration in components/template/template-application-dao-v2/src/main/resources/META-INF/dirigible/template-application-dao-v2/project.json.mjs should be terminated with a semicolon immediately after the closing } of the object literal. Concretely, change line 9 from } to };. No other logic, imports, or definitions are needed, and this will not alter runtime behavior.

In general, the way to fix this is to stop using the deprecated Session.save method and switch to a non-deprecated alternative that preserves the same behavior. For Hibernate, the common replacement for save is saveOrUpdate (which will insert when the entity is transient and update when it is detached), or persist if you know you are always inserting new instances. Since this method is used for generic “save” semantics and returns the identifier, the closest drop-in without changing higher-level behavior is session.saveOrUpdate, followed by retrieving the identifier from the session via session.getIdentifier.

Concretely, in DataStore.save(String type, Map<String, Object> object), on line 155 we should remove the call to session.save(type, data) and replace it with a session.saveOrUpdate(type, data) call. Because saveOrUpdate returns void (unlike save), we then need to obtain the identifier of the persisted entity by calling session.getIdentifier(data) after saveOrUpdate. We keep the transaction boundaries and method signature unchanged so that callers still receive the identifier object as before. No new imports are required, as we are still using the same Session and Transaction types.

In general, the way to fix this issue is to replace calls to the deprecated Session.saveOrUpdate(...) API with the non-deprecated alternative recommended by Hibernate, typically Session.merge(...) (or other state transition methods like persist/update where appropriate). This preserves semantics while avoiding reliance on deprecated methods that might be removed.

For this specific code, upsert(String type, Map object) takes normalized entity data as a Map<String, Object> and then invokes session.saveOrUpdate(type, data). In Hibernate 5.2+ and 6.x, Session.merge(String entityName, Object object) is the non-deprecated analogue which either saves or updates the entity and returns the managed instance. To keep behavior the same and avoid deprecated APIs, we should change line 294 to call session.merge(type, data) instead of session.saveOrUpdate(type, data). The return value of merge is not used here, so we can ignore it. No additional imports are required since merge is already part of org.hibernate.Session. All other logic in the method (starting a transaction, committing, etc.) can remain unchanged.

Concretely:

• In components/data/data-store/src/main/java/org/eclipse/dirigible/components/data/store/DataStore.java, locate the upsert(String type, Map object) method.
• Replace session.saveOrUpdate(type, data); with session.merge(type, data);.
• No other code or imports need to be changed.

In general, to fix this issue you should stop calling the deprecated Session.update(String entityName, Object) method and instead either work with actual entity instances and call the non-deprecated Session.update(Object) or use another non-deprecated persistence mechanism (e.g., JPA EntityManager or explicit SQL). In this class, the store is designed around dynamic Map<String, Object> data and an entity-name string, which makes direct replacement with Session.update(Object) impractical without a larger redesign. The most targeted fix is to replace the deprecated call with an explicit native SQL UPDATE constructed from the data map and executed via Session.createNativeQuery, while still using the existing ParametersSetter utility for binding parameters.

Concretely, in DataStore.update(String type, Map object), instead of session.update(type, data), we will:

1. Extract the "id" (or primary key) from data and throw an exception if it is missing.
2. Build a StringBuilder for a statement like UPDATE {type} SET col1 = :col1, col2 = :col2 ... WHERE id = :id.
3. Use session.createNativeQuery(sql) to create a NativeQuery<?>.
4. Use ParametersSetter to bind all non-id fields and the id field.
5. Execute the update via executeUpdate() and commit the transaction.

This preserves the existing semantics of “update these fields for the given id” using the same normalized map, but no longer relies on the deprecated Hibernate method. It requires only modifying the body of the update(String type, Map object) method in DataStore.java and does not need new imports, since NativeQuery and ParametersSetter are already imported.

In general, to fix this kind of problem, any conversion from a string to an integer (such as Integer.parseInt or Integer.valueOf) that operates on data derived from external or free-form input should be surrounded by a try/catch (NumberFormatException e) block, or otherwise validated before parsing. This allows the code to handle malformed values gracefully instead of throwing an uncaught runtime exception.

For this specific case in EntityParser.java, the best fix without changing existing functionality is to mirror the existing handling used for length. That is:

• Wrap columnDetails.setPrecision(Integer.valueOf(precisionValue)); in a try/catch (NumberFormatException e) block.
• On failure, log or print a warning (consistent with the length handling), and skip setting the precision.
• Do the same for scaleValue and columnDetails.setScale(Integer.valueOf(scaleValue));, since it has the same risk and comes from the same source.

This can be implemented entirely within the shown method body; no new imports are strictly necessary if we keep using System.err.println as with the existing length parsing. Concretely, within components/data/data-store/src/main/java/org/eclipse/dirigible/components/data/store/parser/EntityParser.java, around lines 453–459, replace the direct calls to Integer.valueOf(...) with try/catch blocks that log a warning and avoid throwing.

To fix the problem, the calls that convert precisionValue and scaleValue from String to Integer should handle potential NumberFormatException in the same manner as the existing length conversion: wrap the conversion in a try/catch and handle invalid values gracefully (for example by logging a warning and skipping the assignment). This preserves current functionality for valid input while safely ignoring malformed numeric metadata instead of failing the entire parse.

Concretely, in EntityParser.java around lines 453–459, modify the blocks:

• For precisionValue, change:

  if (precisionValue != null)
      columnDetails.setPrecision(Integer.valueOf(precisionValue));

  to:

  if (precisionValue != null && !precisionValue.isEmpty()) {
      try {
          columnDetails.setPrecision(Integer.parseInt(precisionValue));
      } catch (NumberFormatException e) {
          System.err.println("Warning: Could not parse precision value: " + precisionValue);
      }
  }

• For scaleValue, change:

  if (scaleValue != null)
      columnDetails.setScale(Integer.valueOf(scaleValue));

  to:

  if (scaleValue != null && !scaleValue.isEmpty()) {
      try {
          columnDetails.setScale(Integer.parseInt(scaleValue));
      } catch (NumberFormatException e) {
          System.err.println("Warning: Could not parse scale value: " + scaleValue);
      }
  }

This mirrors the existing pattern used for length, introduces no new dependencies, and keeps behavior for valid numbers unchanged. No additional imports or methods are required.