-
Notifications
You must be signed in to change notification settings - Fork 17
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Inconsistencies in processes (based on pydantic tests) #318
Labels
question
Further information is requested
Comments
Hey @danielFlemstrom, I'm a bit confused and I think I need a bit more context here.
|
Hi @m-mohr!
Thank you for your quick response. Sorry for the confusion. I am relatively new to all this.
As you correctly say, the input is not a python process directly but, one of the Pydantic classes "down the road" is. As a result, a process graph will not be accepted if it includes "non-conformant" processes.
Maybe the most efficient way to access the results of the tests is that I walk you through it in a T-EAMS or Zoom session? Of course, I can zip the models and the test case and mail it to you as well.
|
Happy to join a Teams of Zoom session. That seems indeed like the most efficient way. I'm pretty flexible with meeting slots this week (e.g. today until 4), you could just send an invite. My e-mail address is in my GitHub profile. Thank you! |
Clarified the issues on a video call. Thank you again for your contribution. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
We created Pydantic Classes from the OpenEO API JSON process graph specification and tested them against the standard processes (from https://raw.githubusercontent.com/Open-EO/openeo-processes/1.x.0/)
We found that ['array_apply', 'array_filter'] use
schema": [ {"type": "number"}, . . . {"type": "null"}
instead of
"schema": { "type": ["number", "string", "null"]}
So,
Running the tests against other lists of standard processes reveals other inconsistencies. Not sure how to proceed here in a way that benefits all. PS. the reason we used Pydantic is that FastAPI gives us automatic checking of the API parameters)
Originally posted by @danielFlemstrom in #204 (comment)
The text was updated successfully, but these errors were encountered: