-
Notifications
You must be signed in to change notification settings - Fork 62
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
DictField limitations #99
Comments
Yeah
Don't get it... it precisely the point of
That's a mongo limitation, a workaround would be to serialize all the dict as a single string, but this is doing magic behind the user so I prefer he does this by himself when needed (given it's pretty simple to do with json.loads/dumps)
👍
👍 we should try to stick as close as possible to the upstream marshmallow for the sake of simplicity |
Sorry if I was unclear. I was too focused on the use case I presented in marshmallow-code/marshmallow#483. Let's put it this way, hopefully it will be clearer: class Album(EmbeddedDocument):
name = fields.StrField()
duration = fields.FloatField()
class Artist(Document):
name = fields.StrField()
albums = ... (Assume only one album per year for example sake...) I want {'name': 'David Bowie',
'albums': {
'1971': {'name': 'Hunky Dory', 'duration': 2364},
'1970': {'name': 'The Man Who Sold the World', 'duration': 2456},
}} The only options we have right now for the use case I exposed are
class Album(Document):
name = fields.StringField()
duration = fields.Float()
class DatedAlbum(Document):
year = fields.IntField()
album = fields.EmbeddedField(Album)
class ArtistSchema(Schema):
name = fields.Str()
albums = fields.ListField(fields.EmbeddedField(DatedAlbum)) This is a relatively common use case in my application, since we record data history. What I'm after is a field that would act like a I'm aware of the MongoDB limitation on keys (strings only). But with schemas on the keys, you could use The typed dict thing is not specific to uMongo, so it could belong in Marshmallow. We can wait for Marshmallow or better do the work there. Then add Mongo stuff here. Meanwhile, we may also add that string validator on keys in |
Ok I get it ;-)
I'm not sure allowing not string type for the key is a good idea: if you declare a float as key, you should expect all the (de)serialization stuff done on umongo side, but this is not possible (or would require hard work and less readable code...) for the querying (e.g. Beside, this would open the door to more complex field serialization like EmbeddedDocument, which are totally crazy to try to request against. I think we should only accept string field and validate it then (not
Yup
I would say your example needs dict field that does validation on value while allowing any key. |
Hmmm, right. Let's stick to string keys.
Yes. Or more like class Example(Document):
embd_f = TypedDict(EmbeddedField(EmbeddedExample))
list_f = TypedDict(ListField(FloatField())
int_f = TypedDict(IntField) I think MongoEngine calls it Ideally, we'd solve marshmallow-code/marshmallow#483 but adding a field to uMongo like described above might be an easier path. |
Ok then I'm trusting you on this issue, choose the path you feel the more appropriate (custom |
Yes, that's the alternative. I'm pretty busy right now. I opened this as a note for later, and to get some feedback. If I get a little bit of time, I'll try to add a validation in Then if I have more time, I'd like to give Marshmallow a try and if it is too complicated, go with a custom field here. |
Could you do something like:
|
From marshmallow-code/marshmallow#483:
I could also use this feature, I will look into it, maybe I find some spare time. @bfax: see the comments above: mongodb does not allow keys other than strings, and saving them in another structure would cause confusion for the users. |
I think our best move is to port umongo to Marshmallow 3 and use the new Dict field. |
DictField
suffers from a few limitations.It might be useful to have a schema-less structure, but sometimes, I'd like to have
DictField
enforce a schema. Maybe we could add it extra features or create aTypedDictField
(orStrcturedDictField
, I don't know about the naming).See this discussion in Marshmallow about nesting a
Schema
into aDict
.This comment illustrates the limits of
DictField
.The enhancement proposal is to add the possibility to do this:
Benefits:
Note: uMongo does not complain if a Dict is passed non-string key, but pymongo will raise an
Exception
at commit time. This could be protected by a validator at assignment time in currentDictField
. Obviously, adding the feature described above would solve this by allowing non-string keys.Not sure which approach would be best. Try to solve upstream marshmallow-code/marshmallow#483 and ultimately if rejected implement
TypedDictField
as a marshmallow-bonus field, or createTypedDictField
here as a proof-of-concept and try to have it integrated upstream. The more we can provide upstream, the best, and I saw no objection to the idea, there.The text was updated successfully, but these errors were encountered: