Core: refactor update/delete logic

[jri]

From the architectural viewpoint the various Core responsibilities -- DB access, complex update/delete operations on DM objects, Access Control, creating directives, firing events -- are partly still too intertwined. The current layering approach is not stringent and thus makes the DM Core more and more difficult to maintain. This became evident at least in the face of the required refactoring of the Delete operation (see #833).

Currently the DM objects still have too much responsibilities. After the proposed refactoring the situation looks like this:

• Creating directives and firing events has moved from the DM objects to the persistence layer.
• The complex update and delete logic (for operating on composite structures) has moved from the DM objects to the persistence layer as well.
• The sole responsibility of the DM objects is to let the Core API user operate on persistent (= DB attached) application objects. The DM objects do not contain any retrieval/update/delete logic themselves. Instead they delegate to the persistence layer. Internal core operations do not involve DM objects but take place at the persistence layer.
  The DM objects could be created lazily, that is only when accessed by the Core API user.
• The persistence layer have unrestricted access to the DB. Access Control is performed at a higher level, that is the Core Service.

Note: 3 years ago (DM 4.0.13) it became evident that DM objects should not be responsible for fetch/store themselves. In the course of the former refactoring (see #340) the fetch/store logic has moved to the persistence layer (namely to the TypeStorage and ValueStorage helper classes). Basically now the same will happen for the update/delete operations as well.

See also #933.

[Jörg Richter <jri@…>]

In bbb85bb9eb75f2d6a6266292c9eab3db94af09fc/deepamehta:

Core: refactor delete operation (#935).

See #935.

[Jörg Richter <jri@…>]

In 7d2fd7ce3d0a692b44c8c0e5100b2021b336f183/deepamehta:

Core: refactor delete operation, pt.2 (#935).

See #935.

[Jörg Richter <jri@…>]

In b194f2e0f21eaf8f7d6592b474692ee5d3ef3b09/deepamehta:

Core: refactor delete operation, pt.3 (#935).

See #935.

[Jörg Richter <jri@…>]

In 9457ed272029ebc2848e13e11f467b0dc26de0ae/deepamehta:

Core: refactor create operation (#935).

See #935.

[Jörg Richter <jri@…>]

In 54e6b03de368288eb16ce6972825d5275b7fc978/deepamehta:

Core internal: refactor event manager (#935).

Instantiation of the EventManager has moved from Core Service down to PersistenceLayer.

See #935.

[Jörg Richter <jri@…>]

In da0c8c89a08e07b112eef60123fed22a6ff71218/deepamehta:

Core: persistence layer refactoring proceeds (#935).

The standard distro compiles again and tests run successful.
Hurray!

However, not yet fully functional.
Not yet merged into "master".

See #935.

[Jörg Richter <jri@…>]

In 054b5bc4bb4e15d2ce0de7eeb9fbc1717479e55e/deepamehta:

Core: revise persistence layer injection (#935).

See #935.

[Jörg Richter <jri@…>]

In e6f9153f1f740fae553e76fd9788a0c9e3a3d4de/deepamehta:

Core: make storage decorator methods final (#935).

See #935.

[Jörg Richter <jri@…>]

In bd25d439f647d2005c7af81887117611e7611328/deepamehta:

Core: inject PersistenceLayer? into DMO, pt.1 (#935).

The Core Service is not injected into a DeepaMehtaObject anymore, but the sole PersistenceLayer is.

See #935.

[Jörg Richter <jri@…>]

In 4a78abb19f50ab584644256335d2e1b89177ab2f/deepamehta:

Core: inject PersistenceLayer? into DMO, pt.2 (#935).

See #935.

[Jörg Richter <jri@…>]

In f4aa3e5d8ca225b650566c9d977f64d92d7f4823/deepamehta:

Core: inject PersistenceLayer? into DMO, pt.3 (#935).

Move the TypeCache from the Core Service to the PersistenceLayer.

See #935.

[Jörg Richter <jri@…>]

In 61500c139891e7861125c1b36a7b08d0ee98ac89/deepamehta:

Core: inject PersistenceLayer? into DMO, pt.4 (#935).

The standard distro build again.
The end of the refactoring tunnel is in sight.

See #935.

[Jörg Richter <jri@…>]

In 4c030c43aac84cc16afde4b20118ff77e62128a0/deepamehta:

Core: postDelete listeners receive models (#935).

BREAKING CHANGE

2 event listeners changed:

postDeleteTopic(TopicModel topic)
postDeleteAssociation(AssociationModel assoc)

The passed object is not a DB-attached object (Topic resp. Association) anymore, but a sole model.

Meaning of "DB-attached object": a DB-attached object ALWAYS represents an object that exists in the DB. This means when you modify such an object, e.g. topic.setSimpleValue(...), DM automatically reflects that change in the DB.

Reason for the changed listeners: on post-delete time the very object does NOT exist in the DB anymore. Consequently DM can't pass a DB-attached object. Instead the sole underlying model object is passed.

See #935.

[Jörg Richter <jri@…>]

In 192ee0648a922cdcd1ac3b280202b20e6ae918e8/deepamehta:

Core: fix delete topicmap (#935).

See #935.

[jri]

This greater refactoring is now merged into master.
Please test!

[Jörg Richter <jri@…>]

In 94eca323bb8ad202078a176b5eb2efe2a67b0cca/deepamehta:

Core: polishing (#935).

See #935.

[Jörg Richter <jri@…>]

In 84879f96f58e67af15b7df0ca72d2ff8916118ed/deepamehta:

Core: fix delete type (#935).

See #935.

[Jörg Richter <jri@…>]

In 75cb4ee781280f68df8b0368485af90f6f94ab48/deepamehta:

Core: fix create user account (#935).

See #935.

[jri]

Refactoring the delete logic is basically done.

Now let's tackle the update logic, the Core's most complex affair at all.

[Jörg Richter <jri@…>]

In 26a4048229cfa682758fb7791661c2dafdd80753/deepamehta:

Core: refactor update operation, pt.1 (#935).

See #935.

[Jörg Richter <jri@…>]

In 84377b6edf3fb4095a61012dd0532473b9047e06/deepamehta:

Core: refactor update operation, pt.2 (#935).

Move delete object method from PersistenceLayer to DeepaMehtaObjectModelImpl.
Move update object method from ValueStorage to DeepaMehtaObjectModelImpl.

See #935.

[Jörg Richter <jri@…>]

In 1548f9cd3a31bad40d877f5e478638842f3f0895/deepamehta:

Core: refactor update operation, pt.3 (#935).

Move update-child-topics logic from ChildTopicsImpl to ChildTopicsModelImpl.

See #935.

[Jörg Richter <jri@…>]

In 5f573eee9ca0ebb14e86571ee95de268b73446a0/deepamehta:

Core: refactor update operation, pt.4 (#935).

See #935.

[Jörg Richter <jri@…>]

In 4751115d7fe11a49d26f7848d5cd9dd3c1031d4a/deepamehta:

Core: refactor update operation, pt.5 (#935).

Nice partial success: the Core compiles again.
However, the tests fail.

See #935.

[Jörg Richter <jri@…>]

In c0767b6cbfa6625bb55ce9812f6a81f332731734/deepamehta:

Core: refactor update operation, pt.6 (#935).

Move update-child-topics logic from ChildTopicsModelImpl to DeepaMehtaObjectModelImpl.
Finally it found its place :-)

See #935.

[Jörg Richter <jri@…>]

In a5dca7e31ca6ee237a1e18472626229f25ddb03c/deepamehta:

Core: refactor update operation, pt.7 (#935).

Fix update assoc roles.

See #935.

[Jörg Richter <jri@…>]

In 3deaf27de8b8e6648845f9bad437add5f6f90683/deepamehta:

Core: refactor update operation, pt.8 (#935).

Remove attached object caches from DeepaMehtaObjectImpl and ChildTopicsImpl.

See #935.

[Jörg Richter <jri@…>]

In 0121b24ac58c40d317bf3c36415a1757dab4e61f/deepamehta:

Core: refactor update logic, pt.9 (#935).

BREAKING CHANGE

1 event listener changed:

void postUpdateAssociation(Association assoc, AssociationModel newModel, AssociationModel oldModel)

The newModel parameter is new.

The parameters are now the same as with the corresponding postUpdateTopic listener.

See #935.

[Jörg Richter <jri@…>]

In 73ebed285a696e6963a2440f7ae883008b88b995/deepamehta:

Core: refactor update logic, pt.10 (#935).

Remove attached object cache from AssociationImpl.

See #935.

[Jörg Richter <jri@…>]

In a7a447c7a53d1f13ccd57e32d23bd687e500bbdd/deepamehta:

Core: refactor update logic, pt.11 (#935).

Preparation for refactor update type logic.

See #935.

[Jörg Richter <jri@…>]

In bb1d20136071fb1caf8bf61684bd7b77a00c6ff5/deepamehta:

Core: refactor type update logic, pt.1 (#935).

See #935.

[Jörg Richter <jri@…>]

In 777b3665ff15a564be629a8bf82021ffc7553dd8/deepamehta:

Core: refactor assoc def update logic (#935).

See #935.

[Jörg Richter <jri@…>]

In 6f08dc48f7882470563a0e82455cb59971c35450/deepamehta:

Core: refactor type update logic, pt.2 (#935).

Remove attached object caches from TypeImpl and AssociationDefinitionImpl.

See #935.

[Jörg Richter <jri@…>]

In 3be6b6e9cbc365a15ecc794baca49c8c95756663/deepamehta:

Core: fix assoc def edit (#935).

See #935.

[Jörg Richter <jri@…>]

In f86f21519ac2fc05f9f980d7e439d5ead50de7cb/deepamehta:

Core: refactor type update logic, pt.3 (#935).

Move more logic from TypeImpl to TypeModelImpl.

_addAssocDef()
_updateAssocDef()
_removeAssocDefFromMemoryAndRebuildSequence()

See #935.

[Jörg Richter <jri@…>]

In 14195e4f9d0640b045e26c2ea7e889faa1371a36/deepamehta:

Core: fix data type update (#935).

See #935.

[Jörg Richter <jri@…>]

In 7a5327efdba3d04bfe2ad5bc07ae93a4c7f09f80/deepamehta:

Core: fix add assoc def (#935).

See #935.

[Jörg Richter <jri@…>]

In 0ac181ee3d4ccc61a29932bb2425899f79c8a621/deepamehta:

Core: fix update label config (#935).

See #935.

[Jörg Richter <jri@…>]

In ab052f941d877df1d936e95efa4a7796fb4794df/deepamehta:

Core: refactor type update logic, pt.4 (#935).

Move more logic from TypeImpl to TypeModelImpl.

removeAssocDef()

See #935.

[Jörg Richter <jri@…>]

In a7039b96b07e28854d6f20df4d1636a3567836ba/deepamehta:

Core: refactor delete type logic (#935).

Move delete type logic from TypeImpl to DeepaMehtaObjectModelImpl.

See #935.

[Jörg Richter <jri@…>]

In 505797816d4e1a0b8f0662f8f4685cdc07c4342c/deepamehta:

Core: refactor type update logic, pt.4 (#935).

Move last type update logic from TypeImpl to TypeModelImpl.

See #935.

[Jörg Richter <jri@…>]

In 330d3aaa7961d0f7e2c2f0e80aa6a645d876e477/deepamehta:

Core: refactor type update logic, pt.6 (#935).

Building UPDATE_TYPE directives moved to model class.

See #935.

[Jörg Richter <jri@…>]

In 3884a7abb1a4dde9b8b39605788ca46e3110a21d/deepamehta:

Core: refactor update logic, pt.12 (#935).

Introduce Core internal preUpdate()/postUpdate() hooks.

See #935.

[Jörg Richter <jri@…>]

In 9791f26aafef61e933e8f9fd51081bd1e6995805/deepamehta:

Core: fix assoc def cardinality update (#935).

See #935.

[Jörg Richter <jri@…>]

In 1ce2082d7513889a6f7434b5ab80fcfe5cd65246/deepamehta:

Core: refactor delete operation, pt.4 (#935).

Introduce Core internal preDelete()/postDelete() hooks.

See #935.

[Jörg Richter <jri@…>]

In 75b6bd509273d904f1a90c9ee120b4037f4fbca0/deepamehta:

Core internal: refactor type caching (#935).

The attached type cache is gone.
Only the type model cache remains (as maintained by TypeStorage).

See #935.

[Jörg Richter <jri@…>]

In f8077ec9154ceada6978b56ae5731a0581ab09d2/deepamehta:

Move Type Editor logic to Core (#942, #935).

Deleting a child type in a migration no longer depends on an activated Type Editor plugin.

The server-side Type Editor logic is now integrated into Core.
The Type Editor plugin now contains solely client-side rendering logic.

BREAKING CHANGES

1 call dropped from Core Service:

TypeStorage getTypeStorage()

The TypeStorage has not a public interface anymore.

See #942.
See #935.

[Jörg Richter <jri@…>]

In e6e249bee5f8ea5048be86fccdbf76a4f2527617/deepamehta:

Core: refactor type update logic, pt.7 (#935).

Remove attached object cache from ViewConfigurationImpl

See #935.

[Jörg Richter <jri@…>]

In 43e5b006c0351e0f510109f254e4b96c68899d73/deepamehta:

Core: remove last attached object caches (#935).

Core API

1 new method in DeepaMehtaObject:

Type getType()

See #935.

[Jörg Richter <jri@…>]

In 67ceb7791c665f8fa6cc3237a355f07810134233/deepamehta:

Core: refactor instantiation, pt.1 (#935).

Access check is separated from object instantiation.

See #935.

[Jörg Richter <jri@…>]

In 9923686b51ab13d74bc25dcbe448c7d17b01ce37/deepamehta:

Core: refactor instantiation, pt.2 (#935).

See #935.

[Jörg Richter <jri@…>]

In 719eab9c4e81663aa9a9c1506955742ed3668974/deepamehta:

Merge persistence-layer into master (#935).

A rather big Core refactoring comes to an end.
All update and delete operations have changed, and some retrieval operations.
The various Core responsibilities are now clearly assigned and the architectural layering is proper.

Please test!

See #935.