We need schemaless fields that can handle non-strict json data - lets imagine we are trying to handle 3rd party api that was not designed with jsonmodels first - such api may behave in a way that cannot be handled with models - for example json object with variant names (like list of tags) or list that can contain both scalars and objects (and lists and anything you can write with json).
Although we should keep the mindset 'jsonmodels first can make you data sane' - we should be able to handle more generic cases.
There are some questions for this:
how to handle such data? New fields, or option for current ones?
should we able to allow mixed fields? Like list field that holds scalars and objects - from which (json objects that can be parsed to given (python) model are in fact casted and the rest is left? (That would be complicated)
how to handle data that is schemaless from the root of document? This would be case where we have model, or just scalar, or null - should we even handle such cases?
We need schemaless fields that can handle non-strict json data - lets imagine we are trying to handle 3rd party api that was not designed with jsonmodels first - such api may behave in a way that cannot be handled with models - for example json object with variant names (like list of tags) or list that can contain both scalars and objects (and lists and anything you can write with json).
Although we should keep the mindset 'jsonmodels first can make you data sane' - we should be able to handle more generic cases.
There are some questions for this:
null- should we even handle such cases?