Sometimes multiple projects should be done together. In order to capture this interdependency, we will adjust the application so that a project can contain other projects.
The higher level project will have the combined properties of the individual projects, though some properties can be set on the higher level project, such as section prioritization.
I see three choices for the design:
A model that just has a one to many relation to Projects. the aggregation would need to be done by the view code that uses these models
A model that has one to many relations to project and which emulated the interface of Projects with property() methods. This would always be in synch, but filtering and searching would be tougher.
A model that has all the same fields as the property object (could even be subclass), but has a custom save method that calculates the fields values from the associated projects. Perhaps there is code in the save method (or some other place) that checks if the user tried to set field value directly and raises exception. Would also require setting signals, so that if individual projects are saved, the project bundle is updated too. Benefits are that we filtering and searching will "just work".
Sometimes multiple projects should be done together. In order to capture this interdependency, we will adjust the application so that a project can contain other projects.
The higher level project will have the combined properties of the individual projects, though some properties can be set on the higher level project, such as section prioritization.
I see three choices for the design:
property()methods. This would always be in synch, but filtering and searching would be tougher.