Model code generation #4

Activity

1. vaind

   added

   enhancementNew feature or requestNew feature or request

   help wantedExtra attention is neededExtra attention is needed

   on Sep 9, 2020
2. greenrobot commented on Jun 6, 2023

   

   greenrobot

   on Jun 6, 2023

   Last edited by greenrobot

   Member

   More actions

   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.
3. ivahnenkoAnna

   added 6 commits that reference this issue on Jun 13, 2023

   Add support for vector types #4

   b05650c

   Remove list subscripts and update flatbuffers #4

   44b07dc

   GitLab CI: disable armv7hf #4

   8c717b7

   Fix np array initialization #4

   ...

   84edcc4

   GitLab CI: temporary fix of the mac test #4

   06dfb8d

   Merge branch '4-vector-types' into 'main'

   ...

   e19c686
4. fkromer commented on May 16, 2025

   

   fkromer

   on May 16, 2025

   Last edited by fkromer

   More actions

   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_gen equivalent 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 pydantic BaseModels (very developer-friendly, type validation as default -> less performant) or attrs classes (less developer-friendly, optional type validation -> more performant) instead of using dataclasses (as long as using third-party dependencies is ok). pydantic has 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 objectbox models. 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 objectbox models based on pydantic, attrs and dataclass. This would allow developers to integrate objectbox nicely with any backend independent on their domain model design choice. Cause pydantic is 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.