1.0.0-M1
No due date
89% complete
Primary Goal
-
Add Food Entry
- auto generate secondary key (
code
) next in sequence; realized e.g. by filling in 'auto' in the UI which is then replaced during the transaction when hitting the OK button of the dialog - future work: satisfy creation of mandatory dependants (density factor) --> e.g. provide a separate dialog to populate these
- auto generate secondary key (
Open Questions
- …
Primary Goal
- Add Food Entry
- auto generate secondary key (
code
) next in sequence; realized e.g. by filling in 'auto' in the UI which is then replaced during the transaction when hitting the OK button of the dialog - future work: satisfy creation of mandatory dependants (density factor) --> e.g. provide a separate dialog to populate these
- auto generate secondary key (
Open Questions
- The meta-model (schema) has arrows pointing from (say) entity A to entity B, representing table relations mapped by secondary keys. Where the direction of arrows is indicating A directly depends on B (via a column in A that is member of a secondary key in in B. It would be useful to extend the schema with a flag, to indicate for each arrow whether it is bijective or not. We then could easily generate a rule checker that tests bijectivity on the entire data model. The open question here is, how to model conditional bijectivity. (like e.g. we have alias entries in the food table, which don't require a density factor, whereas other entries do)
- How to implement a Enable/Disable feature for Food or generally any entity?
- Action that operates on the
code
column toggling a!
prefix. (cons: breaks relations) - As an alternative introduce a table that holds secondary keys of entries that are marked for deletion or marked disabled.
- Action that operates on the