Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Architecture Ideas #911

Open
dselman opened this issue Sep 23, 2024 · 0 comments
Open

Architecture Ideas #911

dselman opened this issue Sep 23, 2024 · 0 comments

Comments

@dselman
Copy link
Contributor

dselman commented Sep 23, 2024

Discussion 🗣

Scratch pad of design ideas for a breaking change version of Concerto.

  1. Should be implemented in terms of code generated from the meta model
  2. Should clearly separate the storage of all declarations and their properties from semantic validation
  3. Should separate semantic validation rules from code.
  4. Semantic validation rules should compile to the backend storage layer. They are mostly referential integrity queries and data consistency checks. Some could be explicit on the metadata. E.g. moving from o String superType to --> ClassDeclaration superType would allow the referential integrity check to be generic.
  5. Semantic validation should run async
  6. Should be able to get ALL validation errors, not just the first one
  7. Should be able to detect when/if a model becomes invalid. E.g. raising events.
  8. Should have an edit API to allow declarations to be updated and then re-validated against the rest of the models
  9. Should be FAST and embeddable. C? Zig? Rust? We want a kernel that can be used from multiple languages.
  10. Should support very, very large models. E.g. a graph DB or relational backend as an option? Need some SLAs for this. Should not assume that all models will fit in memory.
  11. Should have indexes for common query patterns. E.g. findDeclarationsByName / findPropertiesByName so that DecoratorManager is fast.
  12. Need to reconcile maps, enums and declarations so maps aren't such as special case in the runtime
  13. Should have a very small core that is just concerned with the above. Can move JSON parsing, generation, validation, serialisation, decoration outside of this core API.
  14. Model the primitive types in the meta model: String, Long, Double, DateTime etc.
  15. Model the base types: Concept, Transaction etc. in the meta model

Context

Detailed Description

@dselman dselman changed the title v4 Design v4 Design Ideas Sep 23, 2024
@dselman dselman changed the title v4 Design Ideas Architecture Ideas Sep 23, 2024
@dselman dselman self-assigned this Sep 23, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant