You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository was archived by the owner on Sep 8, 2025. It is now read-only.
Repository navigation
This repository was archived by the owner on Sep 8, 2025. It is now read-only.
Here I am back. Still working with DateTime fields. At the moment to "slice" (equivalent to startkey/endkey) a ViewResult you need to serialize the a datetime object into a iso format:
If instead of that you use the plain start_time and end_time (that are Python datetime objects) you get a:
TypeError: datetime.datetime(2016, 7, 29, 0, 0) is not a JSON serializable.
What about implementing a native support for that in order to avoid to cast a datetime.isoformat explicitly? Do you see any problems in that? I could try to see if I can implement that.
Theoretically I don't have anything against better support for datetime serialization. However, I'm a bit concerned that we add special handling which does fit well with the CouchDB-Python model, which I think is that we provide a fairly light-weight layer of Python on top of the native CouchDB API. Since JSON just doesn't have native date/time support, people might be surprised at CouchDB-Python doing stuff for them. Also, I would not like to have some kind of partial support in that only top-level objects are converted, so you'd have to add support for date/time objects nested in lists and/or dicts, as well, which will add to the complexity.
However, what would be acceptable, I think, if you create some API to register a custom JSONEncoder class with the JSON encoders/decoders in couchdb.json. Check the Python json/simplejson module documentation for this. (On the other hand, the pluggable encoder/decoder support means that you can probably already do this without changes -- which just goes to show that the API is designed quite well.)
Ok, I did not fully understand what you suggest (just because I'm a newbie here about Python programming). I will read the code in couchdb.json and simplejson to understand what you mean. If I'll need more support I will post back here :).
Activity
djc commentedon Jul 29, 2016
Hey Ruben,
Hi again!
Theoretically I don't have anything against better support for datetime serialization. However, I'm a bit concerned that we add special handling which does fit well with the CouchDB-Python model, which I think is that we provide a fairly light-weight layer of Python on top of the native CouchDB API. Since JSON just doesn't have native date/time support, people might be surprised at CouchDB-Python doing stuff for them. Also, I would not like to have some kind of partial support in that only top-level objects are converted, so you'd have to add support for date/time objects nested in lists and/or dicts, as well, which will add to the complexity.
However, what would be acceptable, I think, if you create some API to register a custom
JSONEncoderclass with the JSON encoders/decoders incouchdb.json. Check the Pythonjson/simplejsonmodule documentation for this. (On the other hand, the pluggable encoder/decoder support means that you can probably already do this without changes -- which just goes to show that the API is designed quite well.)rdbisme commentedon Jul 31, 2016
Ok, I did not fully understand what you suggest (just because I'm a newbie here about Python programming). I will read the code in
couchdb.jsonandsimplejsonto understand what you mean. If I'll need more support I will post back here :).Thanks for now!
djc commentedon Jul 31, 2016
Yeah, questions are always welcome!