Programmatic Support for Arbitrary Attributes

[JeremyCaney]

Background

Generally, it's preferred that attributes we explicitly defined as AttributeDescriptors and associated with a ContentTypeDescriptor in order to maintain and help enforce a reference schema. There are cases, however, where it may be useful to assign one-off attributes to a topic programmatically, even though it may not warrant the overhead of adding an AttributeDescriptor.

Problem

While this is currently supported via the SQL database, these values cannot be directly updated using the SqlTopicRepository. This is because attributes are currently validated against the ContentTypeDescriptor to determine if they should be stored as indexed or extended attributes in the database. Anything that falls outside of that is simply ignored; they aren't deleted, but changes and additions aren't persisted to the database, either.

Challenges

There are some challenges to this which would need to be addressed:

Data Storage

Should arbitrary attributes be treated as indexed or extended? Currently, in the database, they're usually treated as indexed, which makes them easy to find and update. But if they're over 255 characters, that will result in truncation. There are two main options:

1. Default to extended. This is the safest bet, but most arbitrary attributes will likely be smaller, and thus we're losing the benefits of them being indexed.
2. Conditionally store them based on length. In this case, most will be stored as indexed attributes, but it can lead to a confusing condition where the same attribute might be stored in different locations for different topics.

Deletions

How can arbitrary attribute deleted programmatically? Currently, deletions are handled via the UnmatchedAttributes collection which looks for mismatches against the ContentTypeDescriptor and submits those to the database. The best way to address this might be to include any empty or null attributes—even if they don't match the ContentTypeDescriptor—in the UnmatchedAttributes collection.

Note: This exposes a semantic ambiguity with the term "unmatched". In UnmatchedAttributes it means they're defined on the ContentTypeDescriptor but not the Topic. With arbitrary attributes, however, we end up with the opposite scenario.

[JeremyCaney]

If we conditionally store attributes based on their length, we need to account for scenarios where an attribute has legacy versions stored as indexed attributes, which are now in extended attributes. While this works fine from the perspective of the library, it's confusing from the database perspective.

We might mitigate this by treating all extended attributes as unmatched attributes. I.e., if an attribute is stored in the extended attributes store, then any matched versions of it in the indexed attributes store should be overwritten with blanks. This still creates some ambiguity, but it's at least clearer that the legacy indexed version is not relevant.

This also aids in scenarios where non-arbitrary AttributeDescriptors are reconfigured to use IsExtendedAttribute after having been previously stored as indexed attributes.

[JeremyCaney]

This is finished, and will be added to the upcoming release of OnTopic 4.3.0.