define tests workflow, drop obsolete deps#19
Conversation
fix a crash when ordinary field behind discriminator has wrong format
openapi_schema: boolean values should not be valid strings
…array fix format validation of array items
Fix writeOnly behaviour
…nator-type openapi_schema: fix error when passed discriminator has wrong type
* too_short * too_long
…r_msg_in_string_length_restriction_case openapi_schema: extend error message in string length restriction cases
stolen
force-pushed
the
add-github-ci-workflow
branch
from
621ea86 to
2df5e7e
Compare
openapi_schema: count UTF8 code points when checking string length constraints
openapi_schema: fix crash when validating array/map vs const
| ContentType = proplists:get_value("Content-Type", RequestHeaders, "text/plain"), | ||
| {RequestURL, RequestHeaders, ContentType, RequestBody} | ||
| end, | ||
| Result = case httpc:request(Method, Request, [{timeout, Timeout}], [{body_format, binary}]) of |
There was a problem hiding this comment.
В этом месте мне не нравится следующее (и это серьезная проблема эрланга): ты хочешь убрать зависимость от внешней либы и оставить stdlib, но по сути объявляешь это место невозможным к подсовыванию другой имплементации.
Мы точно не внесем ограничений этим переходом?
There was a problem hiding this comment.
Я не вижу серьёзных отличий httpc от lhttpc, если сравнивать с условным hackney -- по сути, у каждого клиента немного свой API, и под это нужно адаптировать код.
Если есть желание сохранить возможность по-быстрому вставить hackney или вроде того, то можно, например строки 65-77 (в предложенной ревизии) вынести в функцию с предсказуемым поведением.
Будет что-то вроде
make_request(RequestURL, Method, RequestHeaders, RequestBody, Timeout) ->
{ok, Status, [{HdrName :: lowercase_string(), HdrValue :: string()}], RespBody :: binary()} | {error, any()}
Тогда можно будет простым патчем заменить клиент (сохранив сигнатуру), а при желании -- даже принимать альтернативные make_request в опциях.
И, возможно, стоит тут заодно уточнить роль openapi_client:
- если это тестовый клиент, то stdlib кажется более предпочтительным, потому что он достаточно хорош для выполнения тестовых запросов, а требований про архитектуре, производительности, etc. примерно нет
- если это продакшн-компонент, то кому-нибудь будет нужен контроль над транспортом (реализация, опции вроде пула, сертификаты TLS, etc.). Тогда понадобится возможность задать свой
make_requestчерез опции.
There was a problem hiding this comment.
@maxlapshin bump
Сейчас предлагаю два варианта:
- вынести поход к HTTP в явную функцию с чёткой сигнатурой (делать её параметризуемой когда возникнет потребность)
- оставить lhttpc как было и отложить решение до новых вводных
Прямо сейчас lhttpc проблем не создаёт.
There was a problem hiding this comment.
@maxlapshin я добавил коммит с тем вариантом параметризации, который предлагаю.
Если ок, то напишу на него тест и документацию.
stolen
force-pushed
the
add-github-ci-workflow
branch
from
2df5e7e to
a8dc196
Compare
3 participants
Uh oh!
There was an error while loading. Please reload this page.