You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When I encode data with Avrora.encode(data, schema_name: @schema, format: :registry), I successfully get back the encoded data.
Actual
Whenever I encode data, I get back {:error, :enoent}. this line tries to read a file that doesn't exist yet. This project seems to assume that the writing schema will always be available locally. For our projects we occasionally have multiple writers of the same schema, so our schema files live independently of the specific projects.
The 0.9.x line seems to behave as expected.
The text was updated successfully, but these errors were encountered:
blatyo
changed the title
Doesn't work with schema registry
Doesn't work with schema registry as source for writer schema
Aug 13, 2020
@blatyo Hey, thanks for the issue. I have a plan to support out-of-band registration and pure reader without any attempt to write the schema. I will do it right after I finish with #39. As a very rough ETA something in 1-1.5 weeks.
With 0.9.x was an issue when people were using reader/writer approach and schemas were never updated because were found in the registry.
The idea is to have an option to say read-only – always read from the registry and fail if not found. Sounds good?
@blatyo Evening, I have some news. In Avrora 0.13 you can find a new configuration option registry_schemas_autoreg which can be set to false. It will prevent schemas from being registered and also read from the disk.
Expected
When I encode data with
Avrora.encode(data, schema_name: @schema, format: :registry)
, I successfully get back the encoded data.Actual
Whenever I encode data, I get back
{:error, :enoent}
. this line tries to read a file that doesn't exist yet. This project seems to assume that the writing schema will always be available locally. For our projects we occasionally have multiple writers of the same schema, so our schema files live independently of the specific projects.The 0.9.x line seems to behave as expected.
The text was updated successfully, but these errors were encountered: