Implement non-SQL based content Store

[wezell]

dotCMS stores content in a database table called “contentlet” (files are on a FS). We need other implementations of the content storage that can store and retrieve content in other ways, such as from a noSQL solution. dotCMS will create a ContentStore interface that can be quickly implemented to store content in a variety of NoSql Solutions (very much like the current CacheProvider interface did for our caching layer) and create a proof of concept NoSQL implementation to store content as JSON on the filesystem under the /assets directory in a B-tree directory structure.

• When a user creates a new ContentType, they will be able to select what Storage Provide they would like to use to store the content.
• All metadata surrounding and tied to a content object's Identifier will remain in the DB, including:
  • Identifier table info
  • VersionInfo Information
  • Permissions
  • Tags
  • Languages
  • Categories
  • Relationships

Content will be indexed in elasticsearch as it is currently regardless of where it is stored.
NoSQL providers can remove the current 25 field type field limits if as their implementation provides.

The StorageProvider would be an option when creating a new content type (Choose Storage:)
maintain all backward compatibility

[Xander-Steinmann]

It would be great if an entire site (including content, but also templates and containers) could be stored in for instance github and 'checked out' on another server.

[Xander-Steinmann]

Another thing that would be great (in the future) is a way to compare/see the changes in a dotCMS instance using a standard tool like git / diff / beyond compare. If the file-based content store is set-up correctly then this should be possible.

[jbjornson]

Why hand-craft your own json store on the filesystem when you can use something like CouchDB/MongoDB/ElasticSearch? These are well tested and robust implementations and will most likely be faster, more reliable and have fewer defects than anything you might implement by hand...

[wezell]

The idea is that the first NoSQL implementation is a POC. It would provide the framework for a pluggable implementation that could include the above stores. A JSON store would require no external dependencies or special configuration which is why it is an attractive first step to us.

[john-thomas-dotcms]

+1 on @Xander-Steinmann comment. This may be a separate issue, but it's tedious and error-prone to compare different versions of content now, and it would be very helpful to have a way to do some kind of a diff to compare versions. It would be ideal to be able to do this both for entire sites or branches (e.g. via a file-based content store) and also from the backend (e.g. History tab).

[jasontt33]

Bump from Virtuoso

[wezell]

This is done in 22.01 - see #21011