Question on behalf of @thomas-soft-grove:
How can I load a document through DataServices without validating it?
We need to migrate some documents because the model has changed and the old documents are now invalid. But if I use DefaultDocumentRepository.getByDocumentReference() it fails with a DocumentModelException.
So how can I migrate such a document in a MigrationStep?
Do we need to do that in plain SQL?
(I know we shouldn’t use DefaultDocumentRepository, but injecting DataServicesDocumentRepository doesn’t work for us)
In <PROJECT_NAME> project, we faced that issue with using DefaultDocumentRepository. getByDocumentReference() to load document before migration, it fails because of the validation (fields were renamed/removed and documents are old).
We changed to use com.mgmtp.a12.dataservices.document.persistence.internal.DocumentRepository (but this is internal and should not be recommended to use, we could write our own DocumentRepository by extending JpaRepository I think), with this we could load all document IDs (or documents) belong to a modelId, we could work on the loaded documentEntity by using xmlDoc of the documentEntity, and do some manipulating on it.
After that, we set back the manipulated xml to the documentEntity, use the com.mgmtp.a12.dataservices.document.persistence.internal.DocumentRepository to save the document to database again.
I hope this will help!
I ended up reading the raw XML directly from the database (through plain JDBC).
After migrating the XML, I used com.mgmtp.a12.dataservices.document.DocumentConvertor to convert that back to an IDocument and save that through an instance of IDocumentRepository (which can be injected automatically). The default DocumentPersisterService can’t be used as it loads the old document before saving a modified document.
I’m not sure if I got you correctly, but following problem might help you to avoid issues.
In case we have many MigrationSteps, and there is data model change in every MigrationStep, then the first Migration will run correctly but the other MigrationSteps, because document has been changed from the first MigrationStep.
For example: old model contains only one group/field (groupA/fieldA)
- MigrationStep 1 (version 1), new field has been added (fieldB, default value = false).
- MigrationStep 2 (version 2), old field (fieldA) has been moved to another group (groupB/fieldA, value also copied to).
So problem is: MigrationStep 1 will load XML from database, add new field (fieldB) into document → correct, but when it converts to IDocument (with newest data model), then old field (fieldA) will loss its value. So in MigrationStep 2, we could not move/copy value to groupB/fieldA.
I hope this will help!
Good point about multiple MigrationSteps - so far we only have one (per release). So the situation you describe can’t happen for us (at least for now).