Repository navigation
Model code generation #4
Description
Activity
To add a "third" option: keep the dynamic aspect (no code generation) but model the entity class like a data class and use additional annotations.
This would be in line with other languages supported by ObjectBox already. I could image that modelling more "as-is" could have other advantages as well; e.g. use additional tooling on it. E.g. PEP 557 mentions static type checkers. I could also imagine the "more static typing" could be of advantage in compiled approaches like Mojo, but that's just a wild guess.
A first step could simply move the model info into annotations, e.g.:
@Entity(id=1, uid=1) class Person: @Property(id=1, uid=1001) id: int @Property(id=2, uid=1002) first_name: str @Property(id=3, uid=1003) last_name: str
Next step after that could be to move ids/uids into a model json and manage that file via some (no need for standard annotations anymore at that point). I think that, at that point, the best thing about this approach becomes visible: the definitions will look quite simple and intuitive:
@Entity class Person: id: int first_name: str last_name: str
Of course, we still need the annotations for certain mappings, e.g. (conceptually):
@Property(type=DateNano) creation_time: int
Or (as-is):
creation_time: Property(int, type=DateNano)
Maybe there are other ways to add metainformation to attributes in Python too? Maybe there is some tooling like we use in Swift that e.g. relies on comments. E.g. conceptually:
// objectbox: type=date_nano creation_time: int
Some research at other similar tools in the Python world could be useful. E.g. SQLAlchemy and Django rather take the initial approach.
- added 6 commits that reference this issue
on Jun 13, 2023 Is there something like dart source_gen that would help with easy-to-use python code generation?
@vaind I don't know of a
source_genequivalent in the Python world.To add a "third" option: keep the dynamic aspect (no code generation) but model the entity class like a data class and use additional annotations.
@greenrobot This is a very good note!
In the modern Python world DTOs are usually implemented using
pydanticBaseModels (very developer-friendly, type validation as default -> less performant) orattrsclasses (less developer-friendly, optional type validation -> more performant) instead of usingdataclasses(as long as using third-party dependencies is ok).pydantichas most built-in features (de-/serialization, validation) for local and non-local DTOs. Consequently it's the most widely used choice.In Domain Driven FastAPI and Django domain model aggregates, entities and value objects are implemented with one of those libs as well instead. It would be incredible helpful if those domain models could be reused as
objectboxmodels. This would elimitate the need for a repository to map between domain and data (persistency) representation.To be most valuable to the Python world the design should allow to use or generate
objectboxmodels based onpydantic,attrsanddataclass. This would allow developers to integrateobjectboxnicely with any backend independent on their domain model design choice. Causepydanticis most widely used it's the best to start with.data persistency (objectbox models in memory/on disk) <-> domain models (objectbox = pydantic models) <-> local-DTOs (objectbox = pydantic models) <-> serialized non-local DTOs (serialized objectbox = pydantic models) <-> frontend.
Currently, the model is declared directly by constructing python objects:
This is a little cumbersome to write and update and thus opens up room for hard to find errors.
It would be nicer if we could generate the model similar to other ObjectBox bindings. There are two ways we do that, e.g. with a language-specific build process integration (e.g. in java, swift, dart/flutter) or with a standalone tool that does code generation (go, c, c++).
Is there something like dart source_gen that would help with easy-to-use python code generation?
If there isn't, then adding "FBS->python" generation support to objectbox-generator would be an option as well.