August summary

The focus for August (and a bit) has been to add support for events. There is now a new changelog screen (e.g. here is the changelog for this blog) where you can see all changes to the content.

Previously there were two different kinds of "events" for content. You could either check the versions of an entity, or check the history of publishing actions for an entity (publish, unpublish, etc). The new events system combines these two into one, and also adds support for changes to the schema. The new events also reflect the atomic nature of some operation, e.g. publishing multiple entities at once result in one event (where it previously created one publishing event per entity), and creating and publishing an event as one action.

Here are the current supported events:

• createEntity
• createAndPublishEntity
• updateEntity
• updateAndPublishEntity
• publishEntities
• unpublishEntities
• archiveEntity
• unarchiveEntity
• updateSchema

Unfortunately the previous events are not migrated to the new system, so you will not see any events for content created before this release. The content is still there, but the events are not.

The new events system also adds support for synchronizing events between different instances of the CMS. If you extract the sync events from an instance of the CMS, you can apply them to another instance of the CMS. This is useful if you have multiple instances of the CMS, and want to keep them in sync. It is also useful if you want to e.g. create a SQLite database with the content from a PostgreSQL database.

The synchronization needs some more work in the future, but is e.g. already used for this blog. All changes to the database are stored as sync events in the git repository, and applied to a new database when the blog is deployed.

Supporting the new events system required getting some fundamental changes to the database: how fields are stored, and how entities are named.

Previously the fields of an entity was stored as a JSON object in an "optimized" variant. E.g. location fields were stored as [latitude, longitude] instead of {lat: 0, lng: 0}. This was done as a premature size optimization, and made it harder to understand the data in the database. So now we store the data as-is (with compatibility with existing data of course through the concept of encoding version).

Another fundamental change is that we now ensure that the name of published entities follow the published version. Previously the same name was used for the published entity and the admin entity. So if you renamed an entity, without publishing the change, the published entity would also be renamed. This is no longer the case.

As part of these changes, functionality for validating content has been moved from the server to the core library. Making it easier to validate content in other contexts, e.g. in the browser.

Getting the new events system in place has been challenging, but it is now in place, and it's been very satisfying to get the fundamentals in place.