--On Tuesday, March 1, 2005 3:51 PM -1000 Takuya Yamashita <[EMAIL PROTECTED]> wrote:
* In the schema level evolution, does the field change reflects the old data in the server too? If so, developers are supposed to carefully think about deleting fields. What if we decided some fields in the existing data is useless and delete it, but in the future they need the same field data again. Should the system support some backup mechanism?
Deleting is, well, destructive. If you want to get rid of a field, but aren't positive that you will never want the data, then the best thing to do is to delete the field, but combine that with a data reorganization method that moves that data from the deprecated list onto the PropertyList (with some kind of key like "archive:Foo" or whatever). That's a safe way to delete fields but not commit yourself to deleting the associated data while still "getting it out of the way".
In the client update inconsistency in the Implementation Issues, should the system support an alert mechanism if the old data is received after the server side is updated? This would be not the kind of active alert to let all users know, but just the users who sent the old data after the server was updated.
Good idea! This is a natural enhancement of our current "Bad Data Alert", which incidentally was the very first alert implemented for Hackystat back in 2001. With this enhancement, though, we will tell users if they need to upgrade their sensors due to structural evolution (as opposed to notifying them that there is some bug in the implementation).
Thanks for the comments, Takuya.
Cheers, Philip
