Closed QSHolzner closed 8 months ago
The Dictionary ENCODERS_BY_TYPE
was renamed to DEFAULT_CUSTOM_ENCODERS
in the newest beanie version (1.23.0).
Hi, Sorry for the late reply. I'll check it and fix during the next bug-fixing session
Is this the suggested way to store dates in MongoDB? AFAICT there's no dedicated date
type; confusingly there is BSON Date type but that's the equivalent of Python's datetime
, not date
.
Hi @QSHolzner , There are many ways people represent date in the database. It can be a timestamp object with zeroes in hours, minutes and etc, it can be a date string and etc. So, there is no standard there. Additionally there is type conflict if I add date type to the encoder (it conflicts with the binary type if I remember correctly). I'd suggest using custom json encoder or not using date time at all, as pymongo maps bson.date to the datetime type.
Hi @roman-right,
Thank you for your answer. I understand that there are different approaches how datetime values are stored in MongoDB. As @gsakkis already wrote there is a date type in BSON which is mapped as datetime
in Python. This is because the date type in BSON always has a time part. We have decided to save a python datetime.date
value as a BSON date with the time element 0. There are certainly different approaches to this problem and it is therefore understandable if an implementation like the one I suggested in beanie specifies too much. For me that's okay, we've already found a solution for our case.
But if beanie is used "out of the box", then the use of datetime.date
in a Document
field currently leads to a cryptic error (ValueError: [TypeError("'datetime.date' object is not iterable"), TypeError('vars() argument must have __dict__ attribute')]
). Perhaps it should be pointed out in the documentation that the datetime.date type is not supported without additional adjustments or a more explicit error message should be issued at the appropriate point.
Hi @QSHolzner , This is a very good point. I will revisit this today and check if I can use default behavior for date there. If no, I'll add this to the doc. Thank you!
But if beanie is used "out of the box", then the use of datetime.date in a Document field currently leads to a cryptic error (ValueError: [TypeError("'datetime.date' object is not iterable"), TypeError('vars() argument must have dict attribute')]).
Agreed; for me this whole section that calls dict()
and vars()
on an unknown object is a risky hack that should be removed and replaced with raising a clear ValueError
message.
Hi, @gsakkis. Would you mind to pick this one up?
Hi @roman-right, you mean the removal of the code I linked to?
@gsakkis this part or the entire problem with the date
type. Both are placed in the same module which you know well. As I understood you have some ideas about the implementation. If you have time for this, for sure.
My understanding based on the discussion above was that Beanie should not include an encoder for date
as there is no standard. Or are you suggesting to use the one @QSHolzner used (BSON date with the time element 0)?
I don't have strong opinion about this specific type. I mean, we can have a default representation for sure. The most important thing here is that the exception is not very intuitive. If not incorrect even.
Describe the bug
If the type of a field is
date
and notdatetime
, then the following error occurs when saving:To Reproduce
If the type of start_date is changed to
datetime.datetime
it works.Expected behavior A Field of type date should be saved in the db as datetime.
Additional context The dictionary ENCODERS_BY_TYPE contains special conditions for certain types.
Would it be possible to include the type date here? In PyMongo only the type datetime is accepted, so it makes sense to convert the date fields in the model to datetime so that they can be written to the DB.
Here is an example of how I extend the dictionry with the special treatment for this type. It would be nice if this is provided by default.