Commit 7a61005
committed
Delete orphaned indexed attributes
If an attribute was previously saved as an indexed attribute, but is then saved as an extended attribute, this can cause ambiguity from the database perspective as there will be two (potentially different) values for the same attribute. This ambiguity is addressed by the `SqlTopicRepository` which will always favor extended attributes—but that isn't immediately clear, and especially when evaluating data in the database.
This scenario is uncommon. Previously, it was most likely to happen if the configuration for an `AttributeDescriptor` was changed to `IsExtendedAttribute` _after_ indexed values had already been committed to the database. It's more common after I added support for saving arbitrary values (9d848f4), however, since these can go from indexed to extended if their length exceeds the 255 character limit for indexed attributes.
Both of these issues can be mitigated by adding all extended attribute keys to the unmatched attributes collection. This collection is used by the `UpdateTopic` stored procedure to delete any unmatched indexed attributes. (In these values aren't deleted due to versioning; instead they are overwritten with a new version with an empty value. The end result is the same, however, since indexed attributes with empty values are no longer returned from the stored procedure.)
Technically, we could have incorporated this logic into the `TopicRepositoryBase.GetUnmatchedAttributes()` method. I chose not to, however, because this is somewhat dependent on the business logic of the specific repository. Not all implementations may treat indexed and extended attributes the way SQL does, and thus the way unmatched attributes are handled may vary.
If we notice overlap in future implementations we can centralize the logic later, but for now it's safer to treat this as an artifact of the fact that `UpdateTopic` uses `GetUmatchedAttributes()` to overwriting _indexed_ attributes, but not _extended_ attributes. (This is because extended attributes are always rewritten in their entirety in the XML field, and so there's no benefit to overwriting them.)
As part of this, to centralize the routine of adding unmatched attributes, the new `addUnmatchedAttribute()` local function was added. It is now used by the processing of both extended attributes as well as `GetUnmatchedAttributes()`.
This supports Programmatic Support for Arbitrary Attributes (#19), while also patching a preexisting issue with changing the configuration of attributes.1 parent 2151a08 commit 7a61005
1 file changed
Lines changed: 16 additions & 2 deletions
| Original file line number | Diff line number | Diff line change | |
|---|---|---|---|
| |||
306 | 306 | | |
307 | 307 | | |
308 | 308 | | |
| 309 | + | |
309 | 310 | | |
310 | 311 | | |
311 | 312 | | |
312 | 313 | | |
| 314 | + | |
| 315 | + | |
| 316 | + | |
| 317 | + | |
| 318 | + | |
| 319 | + | |
| 320 | + | |
| 321 | + | |
313 | 322 | | |
314 | 323 | | |
315 | 324 | | |
316 | 325 | | |
317 | 326 | | |
318 | | - | |
| 327 | + | |
319 | 328 | | |
| 329 | + | |
320 | 330 | | |
321 | 331 | | |
| 332 | + | |
| 333 | + | |
| 334 | + | |
| 335 | + | |
322 | 336 | | |
323 | | - | |
| 337 | + | |
324 | 338 | | |
325 | 339 | | |
326 | 340 | | |
| |||
0 commit comments