How to reference test data across files when application now uses UUIDs instead of stable IDs?

Modeling
1

Hello,

We have a setup where test data is split across several files: brokers, insurers, and two files with a test tender.
Previously, in the test tender files, we could reference related entities using paths like "Broker/6" or "Insurer/28" to point to matching entries in the respective test data files.
However, after upgrading to version 202406-ex1, this stopped working because the IDs are now generated as UUIDs during deployment, rather than being fixed values from the database. As a result, the IDs change every time we deploy locally, which breaks the references in the test tender files and makes it difficult to run consistent tests.

So, please help me if there is any way to reliably reference related test data across files under this new UUID-based system?

Thank you

2

Hello,

The UUID convention for document references was implemented in the DefaultDocumentIdGenerator. I believe you can implement IDocumentIdGenerator for testing purposes.

3

You can try to replace your current test data setup with using rpc initialization scripts (see mgmtp.a12.dataservices.initialization.scripts.jsonRpc configuration properties at Other Initialization Properties) and relationship links. In such a setup you can use the usual rpc operations and placeholder resolution to work with previously created documents in the rpc initialization script. By using relationship links you can make use of the UUID docRefs. This however will be quite some effort to do.

IDocumentIdGenerator is probably not suitable because the id itself is generated without any knowledge of the document for which an id is being generated.

4

Hey,
Since you are having the data already stored as JsonRPC files, I think the easiest solution is to put all the data into one file and use the placeholder resolution:

so in the jsonrpc for the document give a speaking name
{ “jsonrpc”: “2.0”,“method”: “ADD_DOCUMENT”,
“id”: “MyDocumentNumber1”,
“params”: …
}

Then you can use this id in the following way for the links creation:
{
“role”: “Person”,
“docRef”: “#{#MyDocumentNumber1.docRef}”
}

For more info, see the link @andreas-fresh-mesa has shared.

But the data must probably all be in one big file.

5

I agree that leveraging JSON init could probably be simpler, but we still can not have the document references being fixed and determined for testing purposes, right?

That’s decided on how you implement it, you can even have the old incremental id behavior if its correctly done, of course it’d be complicated

6

Because the doc refs are not fix your test runs you would have to first execute some searches to get hold of the document references they need. I hope that there is sufficient information in the documents that you can do those searches for specific documents.

7

That is true, but do you really need fixed docRefs? what for? - or do you just need to reference a given document by its docRef?

8

@felix-blazing-river, sorry, I can not tell, as described in the question, I think they need the fixed docRef. Otherwise, I completely agree that the init JSON approach is more suitable.