More flexible declarative migrations

[jri]

At the moment a declarative migration (= JSON file) can contain 4 entities which DM creates in a fixed order then:

1. Topic Types
2. Association Types
3. Topics
4. Associations

In the course of #341 (Custom Association Types) it becomes a common pattern that Topic Types are defined based on Association Types (namely the "Custom Association Type"). This means the association types must be created first. At the other hand a (composite) Association Type is created on the base of Topic Types, which means the topic types must be created first. So there is no natural order anymore in which the 4 entities must be created. A particular application might require the creation in one order while another application requires it vice versa.

At the moment the only solution is to break the application types into several migrations to force a specific order. However this makes it harder for the developer to keep an overview about the application's data model.

Subject of this ticket is to enhance the declarative migration JSON format in order to

• Create the entities in a specific order
• Allow one entity appear several times in a migration, that is e.g. first create some Association Types, then some Topic Types, then some topics, and finally some Association Types again.

[Jörg Richter <jri@…>]

In 6b4c9bedd78d011456b972f3ab390f701166c65b/deepamehta:

Core: more flexible declarative migrations (#778).

CHANGE

The JSON format for a declarative migration is extended.
A declarative migration can consit of either of these:

1. A 4-property JSON object (the 4 optional properties are: topic_types, assoc_types, topics, assocs).
2. A JSON array of 4-property JSON objects.

The 2nd option is new.
DM processes the 4-property JSON objects contained in the array in order.

Note: DM 4.6 is backward compatible with older migration files.
Your existing migration files are not required to be changed.

See #778.

[Jörg Richter <jri@…>]

In 21bd7e12a2475241f574a2b817fdb31bf7ec799f/deepamehta:

Core: refactor declarative migrations code (#778).

BREAKING CHANGE

1 method removed from DeepaMehtaUtils:

readMigrationFile(...)

This is no longer a public method.

See #778.