Related to the earlier question in the thread: there's one good starting point for a language-agnostic set of test schemas here: https://github.com/apache/avro/blob/master/share/test/data/schema-tests.txt#L24
There's a LOT of other schemas scattered throughout the project and languages, of course. It would be super (but probably a bit magical) if there were a common reference that could be reused across all languages! From the user/community point of view, I would especially find it interesting to have these durable, linkable examples in the docs to use as references. On Sun, Dec 15, 2019 at 12:54 PM Vance Duncan <dunca...@gmail.com> wrote: > > Yes, you’re right. It’s true of any record. It’s rare I end up with no > required field for a record. The idea of a metadata container - such as a > custom “extension” record to a base record - does sound like a meaningful use > case. > > On Sat, Dec 14, 2019 at 3:50 AM roger peppe <rogpe...@gmail.com> wrote: >> >> On Sat, 14 Dec 2019 at 04:58, Vance Duncan <dunca...@gmail.com> wrote: >>> >>> Because you will forever be limited to adding nullable fields to that >>> record. It will forever be a weak contract. That may be OK, depending on >>> the situation. You just won’t be able to enforce semantics through the >>> schema. The code will have to enforce all constraints. >> >> >> As I understand it, that's true when adding fields to any record over time, >> whether the record starts off with ten fields or none. >> >> As you say, it may be OK in some situations, so ISTM that it shouldn't be >> forbidden by the specification. >> >> One possible concrete use case for an empty record is to reserve a field in >> a record for future extensible use; for metadata, for example. >> This could be somewhat nicer than using a map type because you get the >> capability to add specific fields. >> Perhaps the OCF format could have done something like this for the file >> metadata field. >> >> cheers, >> rog. >> >>> >>> On Fri, Dec 13, 2019 at 6:28 PM roger peppe <rogpe...@gmail.com> wrote: >>>> >>>> >>>> >>>> On Fri, 13 Dec 2019 at 23:08, Vance Duncan <dunca...@gmail.com> wrote: >>>>> >>>>> Sorry about that. I was assuming some kind of name-based schema registry >>>>> lookup. Assume you are looking up schemas by name using a schema >>>>> registry. Let’s say the record is name MyRecord. You subsequently add a >>>>> required field to it. Since the new record is not reverse compatible, >>>>> you’ll need to name it MyRecord2, or whatever. This is what I meant by >>>>> “reidentify”. >>>> >>>> >>>> I don't quite get how this is different to having a struct with any other >>>> number of fields. Why should zero be special here? >>>> >>>>> >>>>> On Fri, Dec 13, 2019 at 12:46 PM roger peppe <rogpe...@gmail.com> wrote: >>>>>> >>>>>> >>>>>> >>>>>> On Fri, 13 Dec 2019 at 15:02, Vance Duncan <dunca...@gmail.com> wrote: >>>>>>> >>>>>>> My immediate thought is observe the YAGNI principle and only create it >>>>>>> if and when you need it. Otherwise, you run the risk of requiring >>>>>>> non-interchangeable re-identification if you need required, >>>>>>> non-default, fields when the need materializes. >>>>>> >>>>>> >>>>>> Could you expand a little on that latter point, please? I'm not sure I >>>>>> understand what you're saying. >>>>>> A concrete example might help. >>>>>> >>>>>> cheers, >>>>>> rog. >>>>>>> >>>>>>> >>>>>>> >>>>>>> On December 13, 2019, at 9:25 AM, roger peppe <rogpe...@gmail.com> >>>>>>> wrote: >>>>>>> >>>>>>> >>>>>>> Hi, >>>>>>> >>>>>>> The specification doesn't seem to make it entirely clear whether it's >>>>>>> allowable for a record to contain no fields (a zero-length array for >>>>>>> the fields member). I've found at least one implementation that >>>>>>> complains about a record with an empty fields array, and I'm wondering >>>>>>> if this is a bug. >>>>>>> >>>>>>> A record containing no fields is actually quite useful as it can act as >>>>>>> a placeholder for a record with any number of extra fields in future >>>>>>> evolutions of a schema. >>>>>>> >>>>>>> What do you think? >>>>>>> >>>>>>> cheers, >>>>>>> rog. >>>>> >>>>> -- >>>>> Regards, >>>>> >>>>> Vance Duncan >>>>> mailto:dunca...@gmail.com >>>>> http://www.linkedin.com/in/VanceDuncan >>>>> (904) 553-5582 >>> >>> -- >>> Regards, >>> >>> Vance Duncan >>> mailto:dunca...@gmail.com >>> http://www.linkedin.com/in/VanceDuncan >>> (904) 553-5582 > > -- > Regards, > > Vance Duncan > mailto:dunca...@gmail.com > http://www.linkedin.com/in/VanceDuncan > (904) 553-5582
