Model - Mixin with separate rights (for "view", data layer)

[mdutoo]

Describe alternatives of how to model data layers (INSEE / IGN data layer patcher by Cityhalls data layer use case) using Mixins, from those already possible to those requiring additional developments.

Develop easy ones if any. Put updated description in FAQ / Guide.

1. Different Models & storage (collections)
   • Cityhall creates another Model following IGN's (can be done by adding it as Mixin). It can add a property that models which IGN Resource is patched by a given Cityhall Resource. If it doesn't want to change the existing properties (ex. nomCommune), it can add new ones acting as new versions of the existing ones (ex. cityhall.nomCommune).
   • Then Cityhall copies IGN Resource in it. This can either be done once and for all each year (which may be a costly operation), or when Cityhall needs it.
   • Then Cityhall can patch existing properties, or write new versions of them in the new properties if any.

Limitation : queries on both old (IGN) and new (Cityhall) versions of properties require all IGN Resources to have been copied, otherwise they will only work on the scope of Cityhall patched data (which may be enough for Cityhalls - but won't cover all future uses).

1. Decorating Mixin in same Model (similar to embedded sub Resource)
   • IGN forbids anybody else changing its own data, but accepts that additional data is stored at the same place (collection) when it's done by a trustfull entity such as a national community of Cityhalls.
   • So Cityhalls define properties that model their own version of IGN properties in their own Mixin and add it to the IGN Model.
   • Then they can store patched versions of IGN data without annoying IGN, and make queries on both old and new versions across all data.

Limitation : Cityhalls can't patch existing properties, they must store patched versions of them in their own new properties. And IGN can't get only its own data, it will always also receive Cityhalls (but per RDF principles this shouldn't be a problem at all).

Work to do : Cityhalls must have the right to write their own properties but not IGN's. So rights should be set not only on Models, but on Mixins, and checked at update time. In the MongoDB Entity store, this means each Mixin is in a separate sub JSON Object which holds its own ACLs. By the way, this is exactly how an embedded sub Resource's own rights should be stored, which could then be allowed at the same time.

1. Decorating Mixin externalized in its own Model (another Model is used to define a view)
   • same idea as 2., but Cityhall Mixin is defined in its own Model, rather than IGN's, though it refers ot it. Data is still stored in same collection, but if a query is made on the IGN Model, a filter will apply so that only IGN data is returned (and not Cityhall's).

Work to do : a new kind of Model with said reference and a getCollection() that returns its reference's, said filter

[mdutoo]

Mixin is done, as well as first examples, though how it is used for data layers could be improved. Using it for (dynamic) polymorphism is let to #35. Defining Mixins for technical features is let to their specific issues, such as #19 Contributions and #22 data quality etc. Defining Mixins for core common business types such as oasis.address is let to TODO

[mdutoo]

For views, rather use DCPointOfView which allows to have a alternate, readonly copies of some models' data but reuse others' (in a DCProject which itself allows to fork some data and optionally models but reuse others), since 7d8eb7df2c9217e4a1add4b58f847842c5846abd . Rights may be different on DCPointOfView models.