mirror of
https://we.phorge.it/source/phorge.git
synced 2024-12-30 09:20:58 +01:00
2f1b5ae010
Summary: Ref T5833. Currently, we have an `AlmanacDeviceProperty`, but it doesn't use CustomFields and is specific to devices. Make this more generic: - Reuse most of the CustomField infrastructure (so we can eventually get easy support for nice editor UIs, etc). - Make properties more generic so Services, Bindings and Devices can all have them. The major difference between this implementation and existing CustomField implementations is that all other implementations are application-authoritative: the application code determines what the available list of fields is. I want Almanac to be a bit more freeform (basically: you can write whatever properties you want, and we'll put nice UIs on them if we have a nice UI available). For example, we might have some sort of "ServiceTemplate" that says "a database binding should usually have the fields 'writable', 'active', 'credential'", which would do things like offer these as options and put a nice UI on them, but you should also be able to write whatever other properties you want and add services without building a specific service template for them. This involves a little bit of rule bending, but ends up pretty clean. We can adjust CustomField to accommodate this a bit more gracefully later on if it makes sense. Test Plan: {F229172} Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T5833 Differential Revision: https://secure.phabricator.com/D10777
8 lines
387 B
SQL
8 lines
387 B
SQL
CREATE TABLE {$NAMESPACE}_almanac.almanac_property (
|
|
id INT UNSIGNED NOT NULL AUTO_INCREMENT PRIMARY KEY,
|
|
objectPHID VARBINARY(64) NOT NULL,
|
|
fieldIndex BINARY(12) NOT NULL,
|
|
fieldName VARCHAR(128) NOT NULL COLLATE {$COLLATE_TEXT},
|
|
fieldValue LONGTEXT NOT NULL COLLATE {$COLLATE_TEXT},
|
|
UNIQUE KEY `objectPHID` (objectPHID, fieldIndex)
|
|
) ENGINE=InnoDB, COLLATE {$COLLATE_TEXT};
|