Initialisation sequence in 2023.06

Data Services
1

We got the impression, that import of business models is not completed / commited when we execute our custom initialization logic.

Specifically, if we have added a new field to a model and we import a document in our custom initialization logic that contains the new field, we get an error like this “Deserialization of document has failed. Reason: For the entity instance ‘/X[1]/Y[1]/NewField[1]’, the corresponding entity was not found in the corresponding document model.”

So it seems that we do not have access to the most current version of the model in our custom initialization logic.

In 2025.06 / GetA12 there is the following sentence:

Every step from the table above is executed in its own transaction and is committed right after the step passes.

This sentence is missing in 2023.06 / GetA12

Does that mean, that all initialisation steps in 2023.06 are executed in one transaction?

If so, how can I ensure, that models are properly loaded?

If not, what other reason might exist for that problem? Maybe models are cached, and the cache still delivers the old version of the model? How can i circumvent this?

2

Hi @anon67142020 ,

Before I will be able to answer the question, I need to know a bit more about your use-case. Can you please answer the following questions:

  • Which DS version are you using?
  • Are you using mgmtp.a12.dataservices.initialization.import.models.typesToClear property ? This property is there to ensure that all previous versions of the models are deleted before new versions are included
  • Are you using init-app or regular DS server with initialization sequence ?
  • How are you importing documents ?
  • How are you adding your custom initialization logic ?

You should be able to see new version of models because this is the main use-case for initialization. To update the models and migrate (import) new version of documents.

3

Sorry for the late reply.

Let me answer your questions first:

Which DS version are you using?

36.3.7

Are you using mgmtp.a12.dataservices.initialization.import.models.typesToClear property ? This property is there to ensure that all previous versions of the models are deleted before new versions are included

I do not use typesToClear so far. I am using the default of mgmtp.a12.dataservices.initialization.import.models.enabled (true) together with mgmtp.a12.dataservices.initialization.import.models.path

My expectation: when there is a changed model file in the import-path, it will be re-imported. Model changes are determined by comparing timestamps of the files vs. timestamps kept in the database.

We use includes, and often, only the include models change, not the including models. I expect the including models to be re-expanded when there are changes to the includes.

Are you using init-app or regular DS server with initialization sequence ?

regular DS server

How are you adding your custom initialization logic ?

Like this

 @EventListener
 @Transactional
 public void xxx(DataServicesCustomInitializationEvent event) throws IOException {

How are you importing documents ?

  // read documents from file
  // if document exists 
  documentService.update
  // if not
  documentService.create

I am having a hard time reproducing previously mentioned behavior. It did definitely occur, but maybe in a slightly different scenario:

first start:

  • there was an error in the custom init logic (it ran into an OOM-Error and then everything (?) was rolled back)

second start:

  • error: “Deserialization of document has failed. Reason: For the entity instance ‘/X[1]/Y[1]/NewField[1]’, the corresponding entity was not found in the corresponding document model.”

So it seems that during the first start maybe not everything was rolled back correctly, leading to documents having more fields than expected by the model. But then, as model import should be one of the first steps of initialization, I still don’t get why the models don’t seem to be imported (?) during the second start.

4

Regarding this - business model import - I checked the DS code.

It seems that all models are imported regardless of their timestamps.
All existing models are updated.
It does not seem to matter, if models have been deleted before (via typesToClear).

Am I missing something here?

Should if set typesToClear, to ensure, that the most current versions of my models are imported? If so, could you please elaborate why?

Thanks.

5

Hi @anon67142020,

I reviewed the historical bug tickets to identify whether any previously fixed issues could explain the behavior you are encountering, but I was unable to find a direct match. However, I do recall a bug that might be related. A similar problem is described in this thread: Problem when deploying A12 version 2024-06-ext6.

The issue involved transactions and events triggered during model loads. If an older model is loaded during import, serialization can fail when that model is still expected to be present in the event. The underlying logic is complex due to fallback mechanisms for include resolution and related processes, which makes it difficult to explain in simple terms.

For this reason, we consistently recommend using the typesToClear property to ensure that the models you intend to import are precisely the ones being imported—rather than a merge between imported models and the existing state in the database.

In the upcoming version of A12, we will reduce this complex logic by introduction of the runtime models. This change, will however come only in 2026.06.

6

Thank you @tomas-thin-gale. We will try this.