Attempting to a insert nested key path can stomp on an existing value.

[beelsebob]

What happened

For some key paths, inserting a value can stomp on an existing value in the database.

Client

Other

Browser

Other or N/A

How to reproduce

1. Send the request wget http://<moonraker>/server/database/item --header='Content-Type:application/json' --post-data='{"namespace": "test", "key": "a", "value": 1}'
2. Send the request wget http://<moonraker>/server/database/item --header='Content-Type:application/json' --post-data='{"namespace": "test", "key": "a.b", "value": 2}'

Expected Results:
A 400 response, with the message "Item at key 'a' in namespace 'test' is not a dictionary object, cannot insert."

This happens correctly if you attempt to insert a.b.c after inserting a.b.

Actual Results:
a 200 response, a is replaced in the database with the value { "b" : 2 } instead of 1.

Additional information

No response

[Arksine]

Thanks. Please attach moonraker.log to bug reports reproducing the issue.

This is the anticipated behavior. If you check the log, you'll likely see an entry stating it detected the wrong type for the top level entry and its overwriting it. That said, I can see how this is inconsistent with the behavior of nested keys.

I'll need to think on this. What I don't want to do is change the behavior and break existing clients that presume an insert operation will overwrite the top level key. I could change the behavior of nested keys to overwrite the existing value with a dict.