feat: support list in non-nested mutable json#51
Conversation
|
This makes very explicit what essentially was an unintended (but perhaps fine) behavior that's currently in the library: the top-level isn't always a That was (is?) the basic assumption, but the way The databases seem to be fine with JSON arrays as the top level, so I'm not sure this library should arbitrarily stick to just objects. And even RFC 4627 supports both arrays and objects at the top level, so this seems in line with that and should be supported. |
| return NestedMutableList.coerce(key, value) | ||
| return super(cls).coerce(key, value) | ||
|
|
||
| class MutableListOrDict(Mutable): |
There was a problem hiding this comment.
This should maintain 2 empty lines between definitions (and I guess I should really include black or flake8 with a plugin in the CI runs..)
| any other type by providing the `dbtype` parameter. | ||
| """ | ||
| mutable_type = NestedMutable if nested else MutableDict | ||
| mutable_type = NestedMutable if nested else MutableListOrDict |
There was a problem hiding this comment.
I'm not 100% sure on the name here, but that might be a bit of a wider concern, naming this NestedJson isn't possible as the name gets taken by the column type later (which I think is more generally useful in exports), but getting it to better capture its meaning and then align it with the Nested... variant would be nice.
Suggestions are welcome if you have any.
There was a problem hiding this comment.
Yeah I couldn't come up with a better name either :/
Co-authored-by: Elmer de Looff <elmer.delooff@gmail.com>
yeah, this is what was unintuitive to me and the driver behind the change here. Let me know if any other changes are needed! |
2 participants
No description provided.