Remove ancient FDPMetadata reference from FactoryDefaults and mongodb

[dennisvang]

todo:

• figure out the desired value for className and fix the FactoryDefaults accordingly -> Changed to Metadata following mongodb migration 0002
• create a data migration to fix this in existing deployments -> Turns out there already is a migration that does this, viz. mongo migration 0002, but in a fresh deployment, this migration runs before the FactoryDefaults are applied. This is because RDF triple-store migration 0001 uses FactoryDefaults from the app code, making it immutable, and because the RDF migrations only run after all mongodb migrations have finished.

[dennisvang]

The FDPMetadata class was introduced in 6355b62 (2016), moved into an external package nl.dtl.fairmetadata.model in f1eccfc (2016). This external nl.dtl.fairmetadata package was renamed to nl.dtl.fairmetadata4j in 1df68d3 and then to nl.dtls.fairmetadata4j in 0fa79e0. Also see the (archived) FAIRDataTeam/fairmetadata4j repo.

Finally, c37890f (2020 Apr 4) removed all imports fromnl.dtls.fairmetadata4j in the FDP repo, but did not re-define the FDPMetadata class.

Nevertheless, 0901ba4 (2020 Apr 17) updated the className value in FactoryDefaults to nl.dtls.fairdatapoint.entity.metadata.FDPMetadata, but this class was never (re-)created.

In fact, looking at migration 0002 introduced in c37890f, the actual class name should be Metadata, not FDPMetadata:

FAIRDataPoint/src/main/java/nl/dtls/fairdatapoint/database/mongo/migration/production/Migration_0002_Custom_metamodel.java

Lines 48 to 51 in c37890f

	private void updateAcl(MongoDatabase db) {
	MongoCollection<Document> aclCol = db.getCollection("ACL");
	aclCol.updateMany(new Document(), combine(set("className", "nl.dtls.fairdatapoint.entity.metadata.Metadata")));
	}

However, if we start the latest version of the FDP from a clean slate (empty databases), we end up with the FDPMetadata in the default ACL document in mongodb, so it looks like migration 0002 is not being applied.

As it turns out, this is due to the fact that the ACL documents are created in the RDF triple-store migration 0001, which only runs after all mongodb migrations have completed.

Moreover, the content of RDF triple-store-migration 0001 depends on application code from FactoryDefaults. So, by changing FactoryDefaults in the current app code, rdf triple-store migration 0001 creates a document with the updated className from FactoryDefaults...

FAIRDataPoint/src/main/java/nl/dtls/fairdatapoint/database/rdf/migration/production/Rdf_Migration_0001_Init.java

Line 118 in 0965c4b

return FactoryDefaults.aclRepository(persistentUrl);

This is not how migrations are supposed to work: The migration content is supposed to be immutable, so the factory default should be defined in the migration itself, instead of depending on the actual app code, which may change at any time in the future.

If anything, the reset-to-factory-defaults functionality should depend on the immutable migration content, not the other way around.

In addition, the coupling between the mongo migrations and the triple-store migrations is problematic. I wonder: Perhaps the triple-store migrations should not be migrations at all, but just fixtures that are applied without keeping track of their history? In that case we could simply implement them in the app reset code only, and apply them directly at app start if we notice that the triple store is empty...