TaxonomyField update shouldn't use the database unless necessary about orchard HOT 3 OPEN

I'll do a bit of a stream of consciousness as I try to remember how TaxonomyFields worked, by putting here information I'm gleaning by re-reading the code.

Those IDs (for the terms selected in a TaxonomyField) are NOT already serialized (for either published and latest versions of a ContentItem) in the StringFieldIndexRecord, that is used for queries/projections. OnLoading the terms in the field are populated (in its LazyField) off the records for the TermsPart for the ContentItem. Those records are also used for projections. This is unlike, for example, ContentPickerField.

ITaxonomyService.UpdateTerms: given the list of terms we selected, we want this method to make sure that the TermsPart for the ContentItem we are processing ends up having, for a specific field, only TermContentItems for those terms. Moreover, this method should take all the terms that were unselected to fire off a processing task. Currently, that doesn't work properly, to be entirely honest:

• Start with a ContentItem with selected Term 'A'. Publish it.
• Change selected terms (e.g. unselect 'A' and select 'B'). Save the content as a Draft (don't publish it).
  The records are updated anyway, and when displaying the content it's going to show the information for the Draft TaxonomyField.

It's possible that one way to fix this would be to make the TermsPartRecord a ContentPartVersionRecord. That would also take care of the need to keep track of the changes to the list of terms in the UpdateTerms method, since we'd have new records for the new version. This wouldn't be adding more stuff to the DB than it is now on update, but it would not delete TermContentItem records attached to previous versions: fewer operations, but in the end a larger table.
It would complicate the step done OnPublished to call the task that counts selected ContentItems for each term, but only slightly: we would compare the current version with the previous one to also account for unselected terms, rather than have a separate invocation of the task in the UpdateTerms method.
That "new" versioned part could on principle also have the Ids in its infoset, but it would have to query for all corresponding records anyway, and we wouldn't need to compare the list of Ids to a previous version.

from orchard.

I wasn't really considering versioning, but I agree that it's weird that saving a draft item with different terms selected is immediately reflected in the published version as well.

My immediate concern here is that DB changes happen even when they aren't needed: When you save a Taxonomy Field without changes, the DB operations play out as if you unselected all the terms, saved it and then re-selected the same terms and saved it again, which is wasteful.

from orchard.

Yes. On the other hand, if we moved to a versioned record, that's sort of the default behaviour: the records for the new version, if no change has happened, end up being duplicates of the previous ones (except for the relevant Ids). But we would not be deleting a record just to add it back.

from orchard.