3 ms·

> there is no concept of a "bug" in your data (so patches are meaningless). Is there not? Lets say that you're changing the data in your database/data structur

> there is no concept of a "bug" in your data (so patches are meaningless). Is there not? Lets say that you're changing the data in your database/data structure from state X to state Y. This involves transforming the data in some tables/data structures from the old structure to the new. Lets say that you do this and it's all fine, the upgrade goes great. But then you discover there's a problem with the data upgrade. While you have transformed the data into the new format, it's not been done right. So you actually need a second data change to ensure that your data upgrade is semantically equivalent to the data that went before it, even though the data conforms to your new schema. Would that not count as a bug in your data?

austinpray 10y ago
Any change you make to the schema will be a breaking change.
- webmaven 10y ago
  Not so. Adding a new column is not a breaking change for reads, and may not be a breaking change for writes unless the new column is required, has no default value, and cannot be NULL.
  - sheepmullet 10y ago
    That is not really true in practice. Take for example a GetUserStatistics() call which provides a list of userids and the users last login date. A client might be using this list to get statistics on system usage. If you change the codebase to add the concept of a test user and add an isTestUser column to GetUserStatistics() you have broken the contract with your users. You had an implicit contract based on shared understanding of the data. Now of course to correctly determine user usage statistics you need to exclude the test users by checking the new column.
    - webmaven 10y ago
      Changing the semantics is entirely besides the point. You can change the semantics of the data without making any schema changes at all!
      - sheepmullet 10y ago
        Isn't it the whole point? As a consumer it is what I care about.
- joncrocks 10y ago
  And I'm not discussing changing the schema, but the data contained with the data structures. When transforming the schema, you frequently have associated changes that you apply to transform the data from one form (in the 'before' schema) to another (in the 'after' schema). These transformations are code that can have bugs like any other. In cases like these you can have data that is in the right format, but isn't correct, and can need a second change (to the data only) to correct it.

austinpray 10y ago

Any change you make to the schema will be a breaking change.

webmaven 10y ago
Not so. Adding a new column is not a breaking change for reads, and may not be a breaking change for writes unless the new column is required, has no default value, and cannot be NULL.
- sheepmullet 10y ago
  That is not really true in practice. Take for example a GetUserStatistics() call which provides a list of userids and the users last login date. A client might be using this list to get statistics on system usage. If you change the codebase to add the concept of a test user and add an isTestUser column to GetUserStatistics() you have broken the contract with your users. You had an implicit contract based on shared understanding of the data. Now of course to correctly determine user usage statistics you need to exclude the test users by checking the new column.
  - webmaven 10y ago
    Changing the semantics is entirely besides the point. You can change the semantics of the data without making any schema changes at all!
    - sheepmullet 10y ago
      Isn't it the whole point? As a consumer it is what I care about.
joncrocks 10y ago
And I'm not discussing changing the schema, but the data contained with the data structures. When transforming the schema, you frequently have associated changes that you apply to transform the data from one form (in the 'before' schema) to another (in the 'after' schema). These transformations are code that can have bugs like any other. In cases like these you can have data that is in the right format, but isn't correct, and can need a second change (to the data only) to correct it.