- Sketch main workflows for update and data access with the new storage architecture. Find out which methods and which descriptions (of tables) are required.
- New property_id table. Properties use the same ids whether used as properties or as pages (subject/object)
- property types would be stored in a special table with at most one type per property
- Properties needing a special table will be defined in LocalSettings.php. It can be enough to list the property names; the store can then create a table name from the property name (using a hash on the property name).
- Have an internal mechanism for using special tables for some properties. Use this for some internal special propeties (the necessary tables can be created on setup).
- There could be a table for storing the whole data of one subject as a blob. This could speed up getSemanticData() (without filter) and getProperties(). One could have this as an optional feature that can be enabled in configuration.
- Check why editing a page and saving it without any changes still triggers SMW storage code, and fix it.
- Store an array of hashes for each subject and table (use a serialised array "table"=>"hash" blob for this). Filter updates (delete and write) using these hashes.
- For the moment, do not touch smw_redi2, but do not consider it as a property-value table. It can be ignored in all normal data access methods.