Context Navigation

DataModel

v6	v7
25	25	Then, each resource should have a `<resource>_prop` table, which can be seen as a generalization of the `ticket_custom` table we have now. I think it's enough to have `(name,value)` columns, however, as the type information could eventually be stored in some `resource_schema` table.
26	26
	27	- '''Comment:''' I think that this scheme should be generalized so that there is only one prop table, with provably also more specialized prop tables for the various datatypes. However, this would require a resource_type and a resource_id attribute so that selects will work as expected. Since building queries that would get an object's state in one single query is quite tough, this should be a two stage process, first the resource and then the properties of that resource using unions.
	28
27	29	Also, it might well be that we'll actually need to have datatype-specific property tables, like `<tesource>_prop_int`, `<resource>_prop_text`, even `<resource>_prop_resource` for linking to other resources in a flexible way (TracCrossReferences style).
28	30