Feature/5 verbruiksobjecten

[Floris272]

Changes

• Adds verbruiksobject_schema to product_type
• Adds verbruiksobject to product
• Adds django-json-schema-model dependency repo

[Floris272]

rebased to #36 so that it can be reviewed, will keep this pr drafted to make sure everything is added after #36 & #28

[annashamray]

My main question is about creating separate request for JSON schemas: I think it's excessive and not beneficial.

I don't see a lot of advantage of using django_json_schema_model for now, but I'm also not against it, we can use it and see how it will go

[annashamray]

I don't quite understand why you catch and reraise the same error here

[Floris272]

To generalize the error message, and link it to the field.

[annashamray]

I'll put here my questions about code for django_json_schema_model.models.JsonSchema:

1. It looks like name field should be unique
2. Why do you use Draft202012Validator in the clean() instead of using $schema keyword defined in the JSON schema?

[Floris272]

Instead of validate("{}", self.schema) you mean?

I felt like Draft202012Validator.check_schema(self.schema) was cleaner and it is also what is called within jsonschema.validate.

[annashamray]

same question as above: Why not to use validator based on $schema?

[annashamray]

Why is this line needed? Is including it in Meta not enough?

[Floris272]

Spectacular will render the type of JsonField as any in the type of dictField as object.

[annashamray]

Same comment as above: it's better to define serializer fields explicitly. For example here it's not obvious is PK included in the serializer

[annashamray]

Is it correct that to create a producttype with json schema you need to make two requests?

• create JSON schema
• Use PK of the created schema and create a producttype with such PK

It doesn't look very convenient. Could you just make it in one request?
Moreover I don't think exposing PKs in the public API is a good idea

[annashamray]

Also let's discuss JsonSchema model:
it has name field, which you use as a filter for its endpoint. But you never expose it in the Producttypen endpoint.
So how will user know what schema name to use as a filter

I think it would be better to use Json Schema name instead of PK here

[Floris272]

My idea was that a schema can be linked to multiple product types so because of this, it's created with a separate endpoint and added to a producttype using its id.

I'll make the name unique and use that as the identifier within the api, but i think two requests are always needed unless it becomes a 1 to 1 relation.

[codecov-commenter]

Codecov Report

Attention: Patch coverage is 80.68182% with 17 lines in your changes missing coverage. Please review.

Project coverage is 84.75%. Comparing base (f00b267) to head (d21583a).
Report is 6 commits behind head on master.

Files with missing lines	Patch %	Lines
...rc/open_producten/producttypen/admin/jsonschema.py	0.00%	16 Missing ⚠️
...c/open_producten/producttypen/models/jsonschema.py	95.65%	1 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##           master      #31      +/-   ##
==========================================
- Coverage   84.92%   84.75%   -0.18%     
==========================================
  Files         106      109       +3     
  Lines        2269     2355      +86     
  Branches      149      150       +1     
==========================================
+ Hits         1927     1996      +69     
- Misses        319      336      +17     
  Partials       23       23              

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[Floris272]

After discussing with Alex I decided to remove the package and move the JsonSchema model to open producten.