Allow creation of non-versionized relational content in a FirstSpirit attached DBMS

Dear FirstSpirit community,

in special use cases:

  • import of updated product data from a 3rd party system (thousands per day)

it might not be useful to keep versionized and revision-secure data in a FirstSpirit attached relational Database Management Systems (rDBMS). Actually, there is a directive available that allows setting a FirstSpirit scheme node in "temporal" mode. Here, the value has to be changed from "1" to "0".

Up to now, this change has to be done:

  • within the FirstSpirit Repository Viewer for each project manually (cannot be done easily neither by a FirstSpirit project admin nor a FirstSpirit administrator)
  • does not produce the requested effects where versionized content is not created (details see e-Spirit vendor helpdesk ticket https://helpdesk.e-spirit.com/requests/11939)

So, this feature request recommends:

  • a graphical configuration possibility on FirstSpirit scheme level (not FirstSpirit JDBC layer level as a JDBC layer might be used in multiple FirstSpirit projects simultaneously)
  • per project
  • including a proper DB handling in foreign FirstSpirit projects reading/writing, schema-sync enabled FirstSpirit projects to this type of FirstSpirit scheme

Please vote for this feature request!

Kind regards,

Holger King

2 Comments
king
I'm new here

There is an alternative available where:

- FirstSpirit attached relational database is only used in "read-only" mode and so not FirstSpirit-maintained

A custom application can guarantee the database write handling and update of records. This also ensures:

- less overhead on the FirstSpirit server as the application does not use it

- prevention of a revision-secure and versioning behaviour

The feature request has been placed as there is a directive already existing that seems to allow disabling versioning within the FirstSpirit API. That might help existing FirstSpirit-related implementations (e.g. in FirstSpirit modules) to get rid of versioning data without re-implementing the solution completely new.

dleinich
Occasional Collector

Hallo Mr. King,

as already discussed by phone and explained by yourself in the previous comment, the use case requiring the feature described is easily solvable by using an read-only external database. The use case does not need to make use of FirstSpirit versioning/revisions at all so it's consequently not advisable to use it.

Regarding the temporal attribute in the schema: Setting temporal to 1 (true) is the standard behaviour of FirstSpirit creating new revisions when changing data. Setting this to 0 (false) is the standard behaviour for datasources that are not controlled by FirstSpirit and thus can't keep versioning information.

Although it is possible to modify the schema to use a non-termporal mode for FirstSpirit controlled datasources as well it is strongly discouraged and not supported to do so. There are also no plans to implement this feature at the moment, as many of the core functionalities of FirstSpirit rely on this information being present for FirstSpirit controlled datasources.

As discussed by phone we will decline this feature request. If you have any further questions, don't hesitate to get back to me by mail.

Best regards

Daniel Leinich