Handling of extra keys in fields.Dict

Feature Ideas
1

Yesterday I spent some time understanding why a user was complaining that its client reported that the record was modified when switching to the tree view although he didn’t change anything.

The reason is that there is an additional key in the dictionary sent to client which of course results in the fact that old_value ≠ current_value as the current value is computed from the displayed data.

I understand that but I don’t remember if we discussed the idea of validating only the keys that are defined by the DictSchema . It could be a good idea, because that way if people for some reason add a key to the dict (for the use in an external service) we wouldn’t meddle with ‘their’ data … it’s a bit like we don’t care about additional columns.

What do you think about this?

2

I think we must consider also this case:

  • a key is defined in the schema
  • records are filled with this key
  • the key is removed

In such case the user has no possibilities to ensure that the key is removed for old records. This may be a problem if the data should be removed.

There is also the case of a key definition being replaced by another definition for which the data is not compatible.

And also the case of creating a new key which by chance has the same name as a former and so magically data will appear on old records.

So maybe we should forbid to delete keys but only deactivate them and add a unique constraint on the name.

Indeed at the end it depends if we see the schema as a constraint (like a domain) or as a column definition.

1 Like
3

I had also this case yesterday: a boolean that was turned into a selection.

In this case, my idea was to have something visual around the field to state that something is odd with it (but as you can see it’s still just an idea because the dict could be in another tab, etc so it doesn’t really work).

We could have two kind of Dict fields: the usual one which are just storing some data and StrictDict or SchematicDict (or whatever) which would enforce their schema. Some validation on the client side could be possible for the latter. And for the usual Dict we would need to be more lenient when comparing for equality.

It could work.

4

For me we should add a warning when the definition is modified in an incompatible way.
And ensure that the clients do not crash but just ignore the value if the type does not match.

But to be complete we must forbid to delete schema and just inactivate them.

I’m not sure if we really need to kind. I guess it is better to try to merge both use case.
So with the constraint/warning on the schema, I have no problem in ignoring unknown keys on the client side.