On this page
Metadata and content construction
Last updated on
24 April 2025
Participants
- John VanDyk (organizer)
- Jonathan Chaffer (organizer)
- Dries Buytaert
- Matt Westgate
- Moshe Weitzmann
- Neil Drumm
- Vladimir Zlatanov
- James Walker (day 1)
Deliverables: next-generation flexible content generation and storage. Optimistically, optimization and caching strategy.
Preparation: be familiar with the following:
- JonBob's CCK docs and prototype
- Vladimir's binder module
- John's metadata roadmap and the schema and metatype modules.
Potential strategies
| Approach | Pros | Cons |
|---|---|---|
| Separate table per field type | Easy searches across node types Normalized |
Many joins |
| All columns in node table | SELECT is easy Structure is transparent |
Huge sparse table ALTER Harder multi-values |
| Mixed 1 and 2 | Flexible but allows optimized common case single- and multi-value fields searchable |
ALTER more decisions at run-time |
| Table per node type | node_load very easy easy migration |
ALTER cross-type queries hard hard multi-values |
| #1 with caching | probably fast in both cases | redundant data/sync |
Table per node type is rejected because we are interested in across-node-type searches.
Mixed 1 and 2 is rejected because (1) it has the worst characteristics of 1 and 2 and (2) too much complexity at runtime, and (3) it is complicated enough that we can't bench it without a lot of work. Treat this as a possible future optimization if necessary.
Decision: we will go with choice number 5, which is normalized database tables with node caching.
Help improve this page
Page status: Not set
You can:
You can:
- Log in, click Edit, and edit this page
- Log in, click Discuss, update the Page status value, and suggest an improvement
- Log in and create a Documentation issue with your suggestion
