canmove, Confirmed users
2,056
edits
(miscellaneous clarifications and formatting tweaks) |
(improve formatting of notes) |
||
Line 148: | Line 148: | ||
Some notes: | Some notes: | ||
# The schema uses arbitrary integers to identify all records, even though all tables have another unique column (or, for the prefs table, a unique combination of columns), primarily because in my experience this approach makes future schema changes easier.< | # <p>The schema uses arbitrary integers to identify all records, even though all tables have another unique column (or, for the prefs table, a unique combination of columns), primarily because in my experience this approach makes future schema changes easier.</p><p>Integer IDs might also provide minor space savings and general performance improvements while increasing the complexity of client code and hurting performance for some transactions, but I expect these positive and negative effects to be minor.</p> | ||
# The schema tracks groupers (components that determine the sites to which URIs belong) as a way of namespacing sites created by different groupers. | # <p>The schema tracks groupers (components that determine the sites to which URIs belong) as a way of namespacing sites created by different groupers.</p><p>An earlier version of the schema didn't track groupers, and <strong>I think we should revert to that version, making groupers responsible for namespacing sites in cases where collisions are possible, because I haven't found a good use case for this functionality, while it adds significant additional complexity</strong>.</p> | ||
# Pref values are stored in a column with a <var>BLOB</var> declared type because that type has a <var>NONE</var> type affinity, which means SQLite will do no type conversion on values inserted into the column, maximizing round-trip integrity of data passed from consumers through the service to the datastore and back. | # <p>Pref values are stored in a column with a <var>BLOB</var> declared type because that type has a <var>NONE</var> type affinity, which means SQLite will do no type conversion on values inserted into the column, maximizing round-trip integrity of data passed from consumers through the service to the datastore and back.</p><p>The actual extent of this integrity across the types supported by nsIVariant is yet to be determined and should be investigated via unit tests.</p> | ||
# The <var>prefs.groupID</var> column is nullable to enable the service to store global preferences (i.e. prefs that apply to all sites/the entire web). We could make consumers store such prefs using the existing nsIPrefService, but that would add significant complexity to consumers, which would have to support two distinct and incompatible interfaces (since nsIPrefService doesn't use nsIVariant). | # <p>The <var>prefs.groupID</var> column is nullable to enable the service to store global preferences (i.e. prefs that apply to all sites/the entire web). We could make consumers store such prefs using the existing nsIPrefService, but that would add significant complexity to consumers, which would have to support two distinct and incompatible interfaces (since nsIPrefService doesn't use nsIVariant).</p><p>Supporting global prefs in the site-specific pref service, on the other hand, is straightforward and adds relatively little complexity to its code.</p> | ||
== Service == | == Service == |