...
Decisions
# | Description | Details | Decisions |
|---|---|---|---|
| 1 | Assume flat attributes (no complex data types) but data could be stored as json object in SPI impl. for convenience/PoC | ||
| 2 | SPI should be type safe (the SPI impl. has no access to models)
|
Open Issues
# | Description | Details | Decisions |
|---|---|---|---|
| 1 | SPI Imp NOT using Model (service) current ENM SPI does! | ||
| 2 | the current SPI builds restrictions and has special methods to combine them. Having a fluent interface in my opinion would be way more intuitive and practical. E.g. //AND of two restrictions Restriction and(Restriction firstRestriction, Restriction secondRestriction) //OR of two restrictions Restriction or(Restriction firstRestriction, Restriction secondRestriction) //NOT of a restriction Restriction not(Restriction restriction) This will give any user of the API an intuitive way to build a complex query and the developer of the API a tree to navigate and translate to SQL (or any other query language). A developer could do something the likes of myQuery.setRestriction(restriction1.and(restrcition2).and(restriction3)) |
...