This is an exploration of changing preference storage to proper metacards.
I started with a new interface named Preferences that is a close copy of the PersistentStore interface. Except that the methods no longer have a "type" parameter (the type indicated if the operation was for alerts, notifications, preferences etc), and the methods throw a PreferencesException. The idea was to make an almost-drop-in replacement for the persistent store used in ddf-ui. All of the PersistentStore methods were copied, but it turns only two ("add" and "get(ecql)") were actually used by ddf-ui.
The original preference store contained a single attribute (preferences_json_bin) that contained all of the individual preferences settings. I defined a new metacard type (ddf.preferences) with separate attributes. To keep this first iteration as simple as possible, each attribute is stored as JSON regardless of its actual type (eg. integer, string, map).
For storing, the code takes the single large JSON structure sent by the UI and breaks it down into separate attributes. For retrieval, the code recombines the separate attributes into a single JSON structure. The idea was not yet tackle the UI code. Also, for storing, the code deletes the previous preferences metacard and creates a new metacard. This is not ideal, but it replicates the original behavior. My idea is to add a "patch" method that will allow the UI to update a single preference on an existing preference metacard. That will require a substantial amount of UI work.
There is a bug where a preference setting is getting lost intermittently. I would set the result count in the settings menu and refresh the page. The setting menu reflected the new value, but then sometimes it would revert to the default value. I'm guessing that there is a timing issue with storing the preferences metacard. I update the NRT configuration to include the preferences metacard, but the problem has been resolved. I'm confident that this problem can be solved.
Next Task:
Update Preferences interface to include a "patch" method so the UI can update individual preference values. This is needed so that it plays nice with other parts of the system that eventually update preference settings as well. Once the UI is updated, then the current "add" method can be deleted.
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs within 7 days. Thank you for your contributions.
What does this PR do?
This is an exploration of changing preference storage to proper metacards.
I started with a new interface named Preferences that is a close copy of the PersistentStore interface. Except that the methods no longer have a "type" parameter (the type indicated if the operation was for alerts, notifications, preferences etc), and the methods throw a PreferencesException. The idea was to make an almost-drop-in replacement for the persistent store used in ddf-ui. All of the PersistentStore methods were copied, but it turns only two ("add" and "get(ecql)") were actually used by ddf-ui.
The original preference store contained a single attribute (preferences_json_bin) that contained all of the individual preferences settings. I defined a new metacard type (ddf.preferences) with separate attributes. To keep this first iteration as simple as possible, each attribute is stored as JSON regardless of its actual type (eg. integer, string, map).
For storing, the code takes the single large JSON structure sent by the UI and breaks it down into separate attributes. For retrieval, the code recombines the separate attributes into a single JSON structure. The idea was not yet tackle the UI code. Also, for storing, the code deletes the previous preferences metacard and creates a new metacard. This is not ideal, but it replicates the original behavior. My idea is to add a "patch" method that will allow the UI to update a single preference on an existing preference metacard. That will require a substantial amount of UI work.
There is a bug where a preference setting is getting lost intermittently. I would set the result count in the settings menu and refresh the page. The setting menu reflected the new value, but then sometimes it would revert to the default value. I'm guessing that there is a timing issue with storing the preferences metacard. I update the NRT configuration to include the preferences metacard, but the problem has been resolved. I'm confident that this problem can be solved.
Next Task:
Update Preferences interface to include a "patch" method so the UI can update individual preference values. This is needed so that it plays nice with other parts of the system that eventually update preference settings as well. Once the UI is updated, then the current "add" method can be deleted.