Changes in the Log Database Schema
We have identified a collection of changes we want to apply to optimize the log database
Blueprint information
- Status:
- Complete
- Approver:
- Zeitgeist Framework Team
- Priority:
- Essential
- Drafter:
- Mikkel Kamstrup Erlandsen
- Direction:
- Needs approval
- Assignee:
- Zeitgeist Framework Team
- Definition:
- Superseded
- Series goal:
- Accepted for 0.3
- Implementation:
-
Implemented
- Milestone target:
-
0.3.0
- Started by
- Mikkel Kamstrup Erlandsen
- Completed by
- Mikkel Kamstrup Erlandsen
Related branches
Related bugs
Sprints
Whiteboard
SUPERSEDED: Please disregard the below disucssion. We implemented a fully revamped DB schema at the Bolzano hackfest.
*** Approval
Seif: +1
Markus: -1 (for now)
RainCT: -1 for 0.3.0 (except maybe some smaller bits), +1 for later
kamstrup: +-0 (prioritize API changes, only do DB changes if we have time)
*** Discussion
Seif: I would go with solution 2 for now since it is someway inbetween 1 and 3
---
Markus: I think this spec is not essential for a 0.3 release. As long as the current design is not blocking our work (our goals) for 0.3 we should postpone this spec. The overall database design is a perfect topic for the hackfest. We should focus on the public API for 0.3. A good design of our DB is important and difficult enough for its own release
---
kamstrup: For the record - I agree with both seif and Markus :-)
---
Seif: @kamstrup: so do u approve this feature for a 0.3 development or not
---
kamstrup: @Seif: It's really tricky. The longer we wait to update the DB schema the more users will be locked in. Likewise for our API. I think that we may only be able to complete one of these targets for 0.3 if we are to release soonish. I tend to believe that the API is the most important (we can always migrate the DB via scripts), but I have a feeling that we are going to change the API post 0.3 anyway...
Work Items
Dependency tree
* Blueprints in grey have been implemented.
