U4-11128 - Update ContentService to use new Variant DB table storing content variant information

Created by Shannon Deminick 19 Mar 2018, 11:42:07 Updated by Shannon Deminick 19 Apr 2018, 11:49:22

Is required for: U4-11130

Is required for: U4-11173

Is required for: U4-11179

Depends on: U4-11219

Subtask of: U4-11106

We need to create a new table to store variant information for a content item. Currently a content item is a single structure and the variant information for the content item is stored in a content item's properties with an attached Culture. This is fine for properties but it doesn't work for some other key pieces of data for a variant:

  • Name
  • Published flag
  • Scheduled publishing data

The DB table could be something like:

  • cmsContentVariation
  • name
  • releaseDate
  • expireDate
  • updateDate
  • isPublished
  • versionId (because these values need to be able to be rolled back to)

Stephan has a much better understanding of the v8 DB to make an architectural call on what is required.

Then we will also need to make a DB migration and we will need to update the Content service/repository layer + unit tests to support this.

We should also use this table as the single place to store this data for all content, regardless of whether the user is using variants or not.

Comments

Sebastiaan Janssen 19 Mar 2018, 12:26:56

We will have to revisit this when working on this to make sure we're not going completely out of scope when the 5 storypoints are "spent".


Stephan 29 Mar 2018, 12:28:04

We're going to need more than 1 table. The name depends solely on the language, whereas expireDate and releaseDate depend on language ''and'' segment. Also, the name is versioned (we may want to roll back to an old name), whereas expireDate and releaseDate are ''not'' versioned. Trying to make sense of it all.


Stephan 04 Apr 2018, 09:52:22

Putting the task "on hold" (back to Open) in order to focus on U4-11180


Stephan 11 Apr 2018, 09:20:42

Back on this task - brainstorming w/ mads & co about what we need exactly - design


Stephan 18 Apr 2018, 09:16:14

Work in progress in PR https://github.com/umbraco/Umbraco-CMS/pull/2594


Stephan 18 Apr 2018, 16:43:18

PR has reached a point which I believe is usable, see ContentServiceTests.Can_SaveAndRead_Names() for examples and usage.

Essentially, a content item now has:

  • .GetName(lang) -- gets the name for a given culture
  • .SetName(lang) -- sets the name for a given culture
  • .IsCultureAvailable(lang) -- determines whether a culture is available, ie has a non-empty Name
  • .IsCulturePublished(lang) -- determines whether a culture is published, ie has a non-empty PublishName

A culture becomes available when a name is set for the culture. One can clear that name by setting it to null.

A culture becomes published when one PublishValues() for that culture (regardless of the segment), and is unpublished when on ClearPublishedValues() for that culture (again, regardless of the segment)

It is not entirely clear how this will work with segments.

Some questions remain open. See the ''fixme'' note in Can_SaveAndRead_Names(), for instance. Is there a dependency relation between InvariantNeutral and CultureNeutral? Should publishing values for a culture automatically publish the invariant values? Are we OK with the results of the test method? Etc.

What I still need to do:

  • test it all to ensure it works as intended
  • figure out variations questions mentioned above
  • implement a way to know ''when'' a culture was published
  • implement a way to know whether a culture is ''edited'' (draft != published)


Stephan 18 Apr 2018, 16:49:35

Code has reached minimum viable product stage Moving questions and remaining work to U4-11250 So that this task can be reviewed and merged asap


Priority: Normal

Type: Task

State: Fixed

Assignee:

Difficulty: Normal

Category:

Backwards Compatible: True

Fix Submitted:

Affected versions:

Due in version:

Sprint: Sprint 83

Story Points: 5

Cycle: 9