Adding new defaulted field to schema does not update the contents of the schema

Development
1

Hello, I just wanted to clarify that this scenario is as I describe and expected so we can workaround it:

  1. Have existing schema
  2. Create content for that schema
  3. Add field with a default value to that schema that is “Required”
  4. Go to the existing content
  5. Try to save or publish that content
  6. Validation fails as those new fields have no value despite being having default values

There are a couple of ways we can workaround this:

  • Bulk update content after field is added to populate it
  • Use the scripts to populate it when not present

I am just now worried that if we do not do the bulk update we will have some content with those fields and some without, unless the API defaults them for us when reading them?

I assume we cannot just have a background worker to amend existing content when a field is added as it would mean a whole load of events that could trigger a whole lot of Rules?

Edit: The script approach doesn’t work as the client side validation around “Required” fields kicks in before scripts get run. Here’s what I tried so let me know if I did something fundamentally wrong!
image
image

But the workaround for this is obviously to also set it to NOT be a required field, and if someone tries to set it as “unspecified” then it will just default to false.

2

In general changes to the schema do not update the content. Your solution would work.

I could also create an enricher that updates the content before it is returned from a query, but it still would mean that the DB entry is not updated and that some queries would not work as expected.

Yes, that’s basically the downside of event sourcing.

1 Like
3

If this is something that might be useful for you, please create a feature request.

4

For us we would prefer the DB entry to actually be updated so structure of content is more predictable, (similar to how we wanted to make use of JsonNull to still create fields in Squidex even when field didn’t have a value), we are already working on this bulk updating as we have a bunch of bulk updates we want to make to content. We would treat it as a release and turn off Rules while doing so that we don’t conflict with others making changes at the same time.

Related to the removal of fields is that we cannot Publish content when a field has been removed as we get the “Not a known field” error, is that expected or is it a bug? Workaround is to simply Save and then Publish, but ideally Publish would just ignore those deleted fields and delete them from DB as though a save had been performed.

5

It was actually a feature request, that people wanted to have a full validation of the content again when publishing. And unexpected fields is no different here from required fields.

6

Ah right thanks for the explanation.

7

This is causing us more issues than I originally thought. We have a process that does the following:

  1. Have Published content with a field that was subsequently deleted
  2. Create Draft via API
  3. Patch fields (not the deleted one) on Draft via API
  4. Publish Draft via API - This fails due to “Validation error” and if I go to UI and try and Publish it fails due to “Not a known field”

In this instance I am assuming the deleted field is still present due to using Patching instead of a full Update that the UI does on “Save”?

Am wondering if there is someway of Patching out the removed field, rather than having to do a full Update to get the deleted fields removed from the database records?

Edit: For now our workaround is simply to reintroduce the fields that were deleted (but hidden from API and UI) until we can think of a tidy way of updating the existing content or avoiding this problem.