Umbraco-cms: v8 - radio button editor still stores values as "ID" even though ID doesn't exist

[Shazwazza]

In v7, the radio button editor stored values as the 'id' of the pre-value but this no longer exists, in fact we don't store any of these values by "id" anymore (that was actually a legacy thing of v7). The value of the radio button editor needs to simply store the text of the item that was selected.

Then the radio button property converter should prob be updated/removed

[Shazwazza]

This will most likely also require a data migration to update all existing stored values from their "id" to their string value

[bergmania]

Is blocked by https://github.com/umbraco/Umbraco-CMS/issues/4488. The current state of the branch is, it seems to work as expected if the user manually rebuild and reload the cache after the install.

[nul800sebastiaan]

Maybe I'm missing something but it seems kinda annoying to just store the value, when we change the values weeks later some pages will be expecting the new value while they already had the old value stored.

Also not sure how this would work when you come back to an old page which had a value stored, how will it know what value was actually selected before?

[Shazwazza]

Hi Seb, here's the story and really its about consistency and simplicity.

In v6 we had these editors called something like 'publishing keys', these saved the INT Ids of a pre-value to the value of the property in the database but would put the string versions of these values into the cache. All of this was quite awkward and not many people used these publishing keys editors. The other non publishing keys drop downs would just save the picked string to the db and to cache which was simple. Of course the con of this is what you are mentioning, but it seems that not many people are concerned about this since it's been this way for drop downs for all of v7 and with later versions of v7 the drop downs don't even have this publishing keys option since in later versions of v7 we have the drop down flexible editor and we've actually totally deprecated the publishing keys editors along with all other drop down editors. The drop down flexible just saves the strings chosen in both the db and the cache. We also have other property editors like the color picker, that simply store the string (now object with a label) value chosen in both the db and the cache.

The pros of doing this is: It's simple, there's no overhead with conversions since if we store an ID then we require a database lookup to convert that value, there's less code to deal with this scenario. Your concern here can be addressed in a much better way which we can do post v8 and we can also make this consistent with all of the editors if we think it's important: We can just update all of the values stored in the db and cache that had the previous value with the new one.

But there's a consistency problem, and what I've discovered today goes beyond this task. (It's also worth noting that v8 pre-values behave different from v7. In v8, pre-values are just a json blob, in v7 there was a table for each individual pre-value. So in v8 we don't have an "ID" and currently the editors that are currently saving "ID" are just saving the "Index" value).

We have the: drop down editor, radio button editor and check box editor and all of them should behave the same but they don't. They should all behave like the drop down editor and save the string value chosen in both the db and the cache.

• The Drop Down editors stores STRINGS in both db + cache
• The Check Box editor stores INT "Id" vals but as STRINGS in both db + cache, i.e. "2" or "2,4" and that's because it can support multiple values
• The Radio button editor stores INT "Id" vals as INT in both db + cache, i.e. 2, and that's because it can only support a single value

All of these should just store STRING values and not the "Id" value in both the db + cache. This avoids having to do weird lookups, etc... makes everything consistent and simple. Then if we feel it's important to re-update the DB and Cache when pre-value data is changed we can do that, but I don't think that is critical since it's been like that in v7 since the beginning for many editors.

[bergmania]

Maybe we should consider using another delimiter for * Check Box editor. When we change from ints to the text value , seems quite risky to use, due to the normal usages in strings. Maybe another less used character like e.g. ¤ pr | could be used.

[Shazwazza]

or use json?

[bergmania]

If we ignore the deserialization cost json is by far the best solution. But is it okay to ignore the deserialization cost?

[nul800sebastiaan]

Historically we've done , and | and even ¤ before and.. it always got us into trouble months or years later. So I'd say let's take that small cost.

[clausjensen]

Agree on json - it worked _okay_ with various weird characters, but then people who didn't know about it saw things like these getting transferred in Deploy - thought it was a mistake.. and then removed it, causing all sorts of weird issues.

So by all means - any minor overhead we might see from converting json is far better than having all sorts of weird errors and pitfalls due to trying to micro-optimize.