Closed Chuckame closed 7 months ago
@thake what do you think ?
Sorry for getting back to you on this so late. I think we should consolidate the current ways of naming a record. Have you checked if the @SerialName annotation can cover all use cases?
I don't understand, what it could not work with serial name annot? 😁
I actually don't know because I've not checked it yet. That's why I'm asking you if you have checked it ;)
Everything possible according to the avro spec on naming must be possible with whatever we come up with. I just want to be sure before we settle on a future design.
No issue then, let's plan it as a breaking change to just remove the avro name and namespace annotations to centralize everything using native kotlinx annotations
There is still one edge case: overriding record's namespace of a field. I propose to still remove AvroNamespace
while adding a new AvroNamespaceOverride
that would be only usable on properties. The other advantage is to stop messing with the original AvroNamespace
annotation.
I update the issue's description
Done in #182
Now, to redefine record's name or namespace, just use
@SerialName("RecordName")
or@SerialName("a.good.namespace.RecordName")
(note that record name is now explicit). The goal of kotlinx serialization framework is to be a declarative serialization framework, so if the needs are to have all the records inside a specific namespace and/or all classes with a specific record name, then move all your classes inside this package and name the data classes accordingly.Out-of-the-box:
namespace
:test
record name
:Bar
// After (v2) package test object Bar
Override record's name:
namespace
:test
record name
:foo
// After (v2): package test @SerialName("test.foo") object Bar
Override record's name for a specific field
Having the parent class
Bar
inparent.namespace
and the fieldSubtype
incustom
namespace:Initial problem/proposal
We can mess with priorities because of too much annotations, and avro4k needs caching just to handling those multiple annotations (AvroName, AvroNamespace, SerialName), and also can be ambiguous because of apache's avro java annotations. Also, the native
SerialName
is not fully handled because RecordNaming is using the class name, and I don't exactly understand how the AvroName and AvroNamespace is used since there are a lot of little cases (AvroFixed can change the name by example).This is simplifying a lot the naming codebase, while it also simplifies the api. Maybe we can keep the AvroNamespace to be able to only change the namespace, but since it's the name of the package, just moving classes to the good package seems cleaner and clearer.