Skip to content

This issue was moved to a discussion.

You can continue the conversation there. Go to discussion →

Access subschema from error context? #622

New issue

Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? # to your account

Closed
adjenks opened this issue Mar 20, 2020 · 5 comments
Closed

Access subschema from error context? #622

adjenks opened this issue Mar 20, 2020 · 5 comments

Comments

@adjenks
Copy link

adjenks commented Mar 20, 2020

Schemas can have title properties, as well as description. When an error is returned, I would like to get access to the title and possibly also the description field of that subschema where the error was identified. Is this possible? Currently we get the property, pointer, message and constraint. However, in a nested schema, the pointer doesn't really tell you where to look within the schema itself, so it's difficult to recover the descriptive properties, or extended ("x-property") properties, of a schema. Is there a way to access these in the context of an error that I'm just not noticing?

@erayd
Copy link
Contributor

erayd commented Mar 21, 2020

Can you give an example schema where the pointer is inadequate?

@adjenks
Copy link
Author

adjenks commented Mar 21, 2020

Every schema. The pointer is a pointer for the data structure, not the schema itself.
I want the properties from 9.1 and possibly other properties from the subschema that contains an error. So, when you get an error, how do you inspect the schema, not the data, at the point the error was identified?

@erayd
Copy link
Contributor

erayd commented Mar 22, 2020

Gotcha - I don't think we currently have a mechanism for that. You're welcome to submit a PR that implements it though.

Please note that if you do this, performance is a consideration.

@DannyvdSluijs
Copy link
Collaborator

@adjenks would this still be something you would consider following up on?

At the moment I'm very happy we are able to cleanup the repo and have revived it.
This still didn't solve the problem with the limited time available from the maintainers. So as long
as that remains a problem I'm afraid there is no one besides you that would pick-up this feature.

@adjenks
Copy link
Author

adjenks commented Oct 9, 2024

@DannyvdSluijs I don't think I have the time right now either unfortunately.
I think the ticket should just be left open because I think it would still be a good feature but for now we can just hope someone will pick it up or I will get time eventually.

@jsonrainbow jsonrainbow locked and limited conversation to collaborators Oct 18, 2024
@DannyvdSluijs DannyvdSluijs converted this issue into discussion #760 Oct 18, 2024

This issue was moved to a discussion.

You can continue the conversation there. Go to discussion →

Projects
None yet
Development

No branches or pull requests

3 participants