in #97, I was not sure what I was seeing, but by now, I am pretty sure that the errors I saw there are configdb having leftover data in the json files that have been removed from the schema.
The question, I guess, is: if the schema changes as part of the development process, how to deal with those changes?
In situations, where the change was unintended, it's good to have a warning (although, I would want it to be a bit more obvious, something like stored data does not map to any schema item: <data json>.
In situations where the schema has been changed deliberately, it would be great to have an explicit way to clean up old data. maybe a build switch to tell ConfigDB to remove data that no long adheres to the new schema.
In an ideal world, there would be a way to migrate the schema before the clean up.
the out-of-schema data (what triggers the not in schema message today) is still accessible to be copied to the correct new path and then be deleted from the database.
I wonder if there is a way to automate the process, maybe through a set of properties that tell ConfigDB that a schema entry has been deprecated, deleted or moved_to and ConfigDB would provide debug output accordingly or, in the deleted case, remove the data.
moved to could trigger moving the data to the new location at runtime and use the old location as a pointer to the new location, printing a log message to notify the developer of when the code is still accessing the data. The moved_to location will have to be exact same data type / data structure for ConfigDB to handle it.
deprecated would print the message without actually printing a message
deleted would just delete data that isn't in the schema anymore - at this point, no accessors would be generated anymore and the code generator would create a set of functions that cleans the data on device.
Now, all of this is only necessary to keep user data that already sits within the moved schema portion. In my specific case and where the code is right now, I would be okay with losing a tiny bit of user config and just have data that doesn't comply to the schema be deleted.
in #97, I was not sure what I was seeing, but by now, I am pretty sure that the errors I saw there are configdb having leftover data in the json files that have been removed from the schema.
The question, I guess, is: if the schema changes as part of the development process, how to deal with those changes?
In situations, where the change was unintended, it's good to have a warning (although, I would want it to be a bit more obvious, something like
stored data does not map to any schema item: <data json>.In situations where the schema has been changed deliberately, it would be great to have an explicit way to clean up old data. maybe a build switch to tell ConfigDB to remove data that no long adheres to the new schema.
In an ideal world, there would be a way to migrate the schema before the clean up.
the out-of-schema data (what triggers the
not in schemamessage today) is still accessible to be copied to the correct new path and then be deleted from the database.I wonder if there is a way to automate the process, maybe through a set of properties that tell ConfigDB that a schema entry has been
deprecated,deletedormoved_toand ConfigDB would provide debug output accordingly or, in thedeletedcase, remove the data.moved tocould trigger moving the data to the new location at runtime and use the old location as a pointer to the new location, printing a log message to notify the developer of when the code is still accessing the data. Themoved_tolocation will have to be exact same data type / data structure for ConfigDB to handle it.deprecatedwould print the message without actually printing a messagedeletedwould just delete data that isn't in the schema anymore - at this point, no accessors would be generated anymore and the code generator would create a set of functions that cleans the data on device.Now, all of this is only necessary to keep user data that already sits within the moved schema portion. In my specific case and where the code is right now, I would be okay with losing a tiny bit of user config and just have data that doesn't comply to the schema be deleted.