Alternative implementation of osv_memory using PostgreSQL
Though it is not obvious at first glance, but osv_memory could be much more feature-complete, faster and simpler if it relied on the database engine.
Blueprint information
- Status:
- Complete
- Approver:
- None
- Priority:
- Undefined
- Drafter:
- None
- Direction:
- Needs approval
- Assignee:
- Vo Minh Thu
- Definition:
- Approved
- Series goal:
- None
- Implementation:
-
Implemented
- Milestone target:
-
6.1
- Started by
- Numérigraphe
- Completed by
- Numérigraphe
Related branches
Related bugs
Sprints
Whiteboard
Please discuss this blueprint on the Framework Expert mailing list, and report only conclusions here.
Basic proposition:
osv_memory provides a convenient way to store transient data as in-memory objects.
Currently this is used mainly for configuration wizards, but there are lots of other use cases for this.
However the current implementation is incomplete and much slower than regular osv objects.
In great part, this is due to the efficiency of PostgreSQL and the SQL language, as opposed to python code and hand-coded searches.
Furthermore, PostgreSQL uses memory in a much smarter way, keeping data in memory only when it is used.
So the conclusion is that we could implement osv_memory in a much better and simpler way by just adding a few missing features to the regular osv/orm:
- data should be deleted when the server starts and stops
- vaccum function
Discussion:
Some technical aspects have been emphasized: we could use sqlite or PG temporary tables (though we must take care of lifespan problems). Insisting on keeping objects in RAM may be a bad move.
Implementation:
This blueprint has been implemented in the trunk for v6.1 by the core team. Numerigraphe didn't do it but Launchpad insists on showing they did.
