GitLab

--HG--
branch : 0.2

--HG--
branch : 0.2

- Add a test for object relations
- Change _relation_mapper signature to accept "role"
- Add a _relations attribute that contains relation/role pairs
- Use the new _relations instead of the old relations attribute
- Hide subject and object relations mapped to this document from etype JSON Schema
- Add 2 tests to detect relation duplications
- Detect relation duplications

--HG--
branch : 0.2

JSON Schema validation of an instance is arguably the responsibility of
the client and it's not very useful to (re-)validate the instance on
server side with a JSON Schema validator since we already have a
validation in the database.

Also, it creates problems with combined usage of "default" and
"required" when the client does not supply a value (which is
legitimate). Closes #17115851. (Added a test for this.)

In ETypeMapper.values(), we now check that "instance" is completely
consumed when all mappers of the graph have been called and if not, we
issue a validation error similar to what a JSON Schema validator would
have raised since we have `"addionnalProperties": "false"` on our JSON
Schema.

There's no behaviour change in tests, just some error messages changes.
Useless tests are dropped.

We do not depend on python-jsonschema anymore in application code, but
only in tests.

--HG--
branch : 0.2

The latter works by using whatever python3 executable points to.

--HG--
branch : 0.2

--HG--
branch : 0.2

--HG--
branch : 0.2

There appears to be no reason to have name unicity amongst
all entity types.

--HG--
branch : 0.2

All subclasses of BaseRelationMapper but AttributeMapper override this method
which behavior is actually only valid for attribute-relation.

This is useful to had PUT requests working with a body containing all required
fields with unmodified values for attributes for which update is not allowed.
Added a test highlighting this.

Implement a "_type" method for DateMapper (which DatetimeMapper inherits from)
that parses the string date as ISO8601 format (similar to what we render in
the HTTP API). Add a dependency on iso8601 package that provides a parser for
this.

In many cases, such errors would occur for an internal reason not because of
an invalid request. So prefer "500 Internal Server Error" over "400 Bad
Request" which might be misleading if the error is actually "internal".

Later on, we should make a proper distinction between true internal errors and
*currently unhandled* client errors. One such case concerns converting
TypeResolverException that might occur when setting a relation to a bad target
into a proper Bad Request (hence the "TODO" in respective test).

As demonstrated in test, this might occur if an exception with no message is
raised (str(exc) == '').

Since "entities" and "schema" resource trees have the same structure, keeping
both induces some duplication. We use "entities" resource in schema API views
(where "schema" resources were previously used) and adjust a few things here
and there to keep things working:
*   the "described_resource" link between entities and schema resource is no
    more needed in "links" appobjects since we only have the "entities"
    resource there now;
*   similarly the "described_by" link (reverse of "described_resource") is no
    more needed.

Rename the route for schema into "cubicweb-jsonschema.schema" to make it
consistent with entities route (named "cubicweb-jsonschema.entities").

See previous patch for why.

By using this method and the entity resource, we avoid coupling the view with
route name. In tests, lower case the "etype" segment of response Location
header as the name of EntityResource is lower case.

By using RootResource as a factory we can have a single route for all entities
view (except for the DELETE view for single entity). We rename the route as
"cubicweb-jsonschema.entities" to make it closer to the schema route name.

We want to have a single route factory for "entities" views, this factory
should be RootResource as it matches the first segment of traversal. So add a
__getitem__ method to this class to retrieve ETypeResource. This will be used
in forthcoming changeset.

Without a network connection, jsonschema validation would fail because
external references cannot be retrieved. Issue a warning instead of failing in
this case.

Otherwise pytest collection fails because of migration/postcreate.py which
fails to execute outside cubicweb migration environment.

For instance, before this change, the `in_group` relation of a CWUser was not
required per generated JSON Schema despite it has a `minItems=1` constraints
because the `in_group` property was not listed in "required" constraint of the
main document.

Update many tests with an incomplete "instance" accordingly.

From the code of validation_failed(), "detail" variable might be an empty list
so that \n'.join(detail) might be an empty string. When "detail" is empty, do
not pass it in kwargs instead. Handle 'invalid-params' key in a similar
manner for consistency.

This predicates would now match on any class attribute with a name usable for
`yams_match` predicate.

Previously (I don't remember why), we used the name of a class (i.e.
target_type) in DocumentField initialization for target fields of
InlinedRelationMapper. This causes problem when trying to render the schema of
the field for such a relation if respective document is not in JSL registry
(it might not at this point apparently). By using the class directly we avoid
a registry lookup later when schema of the document field is requested.

Added a test checking that schema of an inlined relation renders correctly.

Instead of passing `takefirst=True` to rdef(), we use kwown target type from
selection context if there's only one possible target type. If there are more
than one possible target types, we set description to None. Otherwise, pass
targettype=None to rdef as it's probably a final relation hopefully not
ambiguous.

Switch from jsonapi errors style to RFC 7807 [1] errors.

[1] https://tools.ietf.org/html/rfc7807

Closes #17073910

Split view for requests with ?role=<schema_role> from main schema view for
related entity. In the latter export hyper-schema links based on selection
context.

Extent tests in hypermedia-walkthrough.rst accordingly.

We drop the specialized version of "collection-item" link and use the latter
instead. This way we have correct "href" for rel="item" links of related
collection (for instance on the "topics" relation, we have
href="/book/<book id>/topics/<topic id>"). Navigation from related collection
to related item is now symmetrical to collection/item for entity types.

Extend tests in Hypermedia walkthrough accordingly.