Fix broken ETS references

[Strech]

This PR include 3 major changes:

1. Avrora.Name module was moved to Avrora.Schema.Name
2. Avrora.TestCase helper module gets cleanup_storage!/1 function to clean storage between tests
3. Avrora.ETS module now supervisioned together with Avrora.Storage.Memory and owns all ETS tables generated by Avrora.Schema

Resolves: #21

[fxn]

I have read some source code.

Now I see that ETS is a backend for avro_schema_store.

Only feedback is that, in a first read, it seems slightly odd to me to use the generic API for ETS instead of :avro_schema_store.new/1, which would be consistent with the rest of API usage. The name of the module could also be more concise perhaps. You know what I mean, that all related to wrapping avro_schema_store feels coherent.

Also, that ETS table could have an informative name (can be passed to :avro_schema_store.new/1 as well), and then schemas would not need to carry references to the lookup table, because a name in the API calls would suffice.

Only some feedback since I said I would read the source code :). Of course, the current code does the job and my comments are details based mostly on personal preferences, no need to change anything unless you like some of those ideas.

Thanks for this library!

[Strech]

@fxn Thanks for your effort, let me follow up:

1. Only feedback is that, in a first read, it seems slightly odd to me to use the generic API for ETS instead of :avro_schema_store.new/1

Yes, I have that in mind, and first draft was doing exactly as you said, but :avro_schema_store.new/0

2. The name of the module could also be more concise perhaps. You know what I mean, that all related to wrapping avro_schema_store feels coherent.

Again – you are right, I spend so much time to come up with a nice name and as you see I change it to ETS and that was a reason why I have changed from :avro_schema_store.new/0, to :ets.new/2 ... and I can find out a better name to kind-a wrap :avro_schema_store, I think I would switch back

3. Also, that ETS table could have an informative name (can be passed to :avro_schema_store.new/1 as well), and then schemas would not need to carry references to the lookup table, because a name in the API calls would suffice.

Ok, here we have a more complicated situation. Since the same schema can be represented with few Avrora.Schema naming becomes cumbersome and to avoid collisions I decide that reference is a 100% working case. Also, naming will not save us from tables to be wiped, and the host process is still needed. So I consider names instead of references a costly change which will not give us many benefits.

P.S Just in case if you have in mind any name example for Avrora.ETS it will be great, but I think renaming and :ets to :avro_schema_store change is definitely a thing to do.

[fxn]

Ok, here we have a more complicated situation. Since the same schema can be represented with few Avrora.Schema naming becomes cumbersome and to avoid collisions I decide that reference is a 100% working case. Also, naming will not save us from tables to be wiped, and the host process is still needed. So I consider names instead of references a costly change which will not give us many benefits.

Can you elaborate on this? While reading the source code of avro_schema_store.erl I got the impression that the intended usage of the API was to have one ETS table in which all types are stored.

[Strech]

@fxn Yep, they use schema store as one storage for all schemas you might have. But in our case, we can have a schema registry and the same schema can be represented with different versions. You can't have in one storage the same schema with different definitions.

That's why one schema is a small universe with its own storage where it will be decomposed on sub-definitions and lookup functionality becomes available from :avro_schema_store.

---

UPD: Schema decomposition happened when you add type to the :avro_schema_store, all records will be extracted and placed in a top-level to allow you quickly find them with :avro_schema_store.lookup_type/2