I wholeheartedly agree. The registry seems like a pain at first, but it will give immeasurable benefits (not long) down the line. Schema evolution is perhaps the single most powerful differentiating feature of Avro. The schema registry is the prescribed means of handling version lookup. It's a no-brainer, really.
Good luck! On Mon, Dec 30, 2019 at 2:32 PM Lee Hambley <lee.hamb...@gmail.com> wrote: > Hi Martin, > > I believe the answer is "just use the schema registry". When you then > encode for the network your library should give you a binary package with a > 5 byte header that includes the schema version and name from the registry. > The reader will when go to the registry and find that schema at that > version and use it for decoding. > > In my experience the naming/etc doesn't matter, only things like defaults > in enums and things need to be given a thought, but you'll see that for > yourself with experience. > > HTH, Regards, > > Lee Hambley > http://lee.hambley.name/ > +49 (0) 170 298 5667 > > > On Mon, 30 Dec 2019 at 17:26, Martin Mucha <alfon...@gmail.com> wrote: > >> Hi, >> I'm relatively new to avro, and I'm still struggling with getting schema >> evolution and related issues. But today it should be simple question. >> >> What is recommended naming of types if we want to use schema evolution? >> Should namespace contain some information about version of schema? Or >> should it be in type itself? Or neither? What is the best practice? Is >> evolution even possible if namespace/type name is different? >> >> I thought that "neither" it's the case, built the app so that version ID >> is nowhere except for the directory structure, only latest version is >> compiled to java classes using maven plugin, and parsed all other avsc >> files in code (to be able to build some sort of schema registry, identify >> used writer schema using single object encoding and use schema evolution). >> However I used separate Parser instance to parse each schema. But if one >> would like to use schema imports, he cannot have separate parser for every >> schema, and having global one in this setup is also not possible, as each >> type can be registered just once in org.apache.avro.Schema.Names. Btw. I >> favored this variant(ie. no ID in name/namespace) because in this setup, >> after I introduce new schema version, I do not have to change imports in >> whole project, but just one line in pom.xml saying which directory should >> be compiled into java files. >> >> so what could be the suggestion to correct naming-versioning scheme? >> thanks, >> M. >> > -- Regards, Vance Duncan mailto:dunca...@gmail.com http://www.linkedin.com/in/VanceDuncan (904) 553-5582
