Thomas Jaeckle

I think it makes sense to close this issue as it is not on Ditto's goals to natively support historical data. Integration with other TS databases is IMO the better...

Hi Zubair. I recently thought about something which might help you (but I'm afraid this is only a first idea). But would be great to get a feedback whether this...

I agree - should not be possible to transitively inherit policies ... that really makes things complicated, also for the user of such a feature.

Changed the title as introducing multiple policies for a single thing is difficult without breaking the JSON format.

2 years ago I did a little proof of concept - I now pushed that onto a branch: https://github.com/eclipse/ditto/tree/lab/policy-imports However, that branch does not yet compile and policy enforcement most...

The Ditto team is planning to start working on this topic. We would like to use the former PoC at branch https://github.com/eclipse/ditto/tree/lab/policy-imports and also the stale PR #993 as a...

> With transitive imports, I'm assuming you mean that i.e. PolicyC cannot import "end-user" from policyB (because that was imported by policyB itself)? So essentially, we can only construct policies...

That sounds reasonable. What we would need then is a class/enum/whatever where the Ditto "known metadata" fields are defined. "Knowing" meaning that Ditto has to apply semantic meaning to that...

Just to clarify: #298 would also let you do exactly what you described, won't it? Because I think that this would API-wise be a better enhancement than e.g. adding an...

I'm afraid that breaking the JSON API is not a short- to midterm option, at least not until Ditto requires other JSON breakages in the "thing JSON" which would justify...