Closed jotelha closed 1 year ago
An instance of this branch runs at https://demo.dtool.dev/, with openapi docs at https://demo.dtool.dev/lookup/doc/swagger, would like to discuss.
Broke what's left here down into several small pull requests,
Closing this one.
This is an old pull request I had still open on Luis' fork (https://github.com/ljyanesm/dtool-lookup-server/pull/1), with a few points not discussed yet. Below I copy over what I still find relevant. A few of the issues described arose when playing with auto-generating Python API from the openapi specs (https://github.com/jotelha/dtool-lookup-server/tree/0de6f54d0912c79740c9089228f2c5c764babf26/devel).
Uri
toURI
in models and schema for all occurrences.URI
acronym likeBaseURI
,BaseUri
,BaseURISchema
, andBaseUriSchema
insql_models.py
andschemas.py
caused troubles for autogenerated Python client API. For now, resorted to suffixSQLAlchemy
for the schema defined withinsql_models.py
due to a lack of imagination. Do we actually need the different schema insql_models.BaseURISQLAlchemySchema(ma.SQLAlchemyAutoSchema)
andschemas.BaseURISchema(Schema)
?sql_models.Dataset(db.Model)
defines columnsfrozen_at
and created_at as db.DateTime()
, its methodas_dict()
converts those withdtoolcore.utils.timestamp(self.frozen_at)
. This, however, results in the autogenerated client API to expect a serializeddatetime
object and to throw an exception when receivingfloat
. Treatcreated_at
andfrozen_at
as floats in schema with https://github.com/jotelha/dtool-lookup-server/blob/9d1b8cc751f1d1e143bae10d9454d86be438dc13/dtool_lookup_server/sql_models.py#L122-L128 as suggested below https://marshmallow.readthedocs.io/en/latest/quickstart.html#implicit-field-creation. Not sure whether this is legitimate.treat UUIDs as string for now, keep https://pymongo.readthedocs.io/en/stable/examples/uuid.html#handling-uuid-data in mind.