I think the spec is OK with it. We've even used it in the Java API (to refer to a table had been created but had no columns yet). It's not *extremely* useful even as a starting point to add schema evolutions, but maybe as a technique for forcing different Parsing Canonical Forms for otherwise identical schemas? The no-field record wouldn't be stripped, but still serializes down to zero binary bytes.
We actually ran into the following problem: how many records (of size zero) can you decode from an empty stream of bytes? If I remember correctly, the Java API will happily read zero-byte records forever, so if you're going to use this technique, make sure you have a stopping condition! Ryan On Fri, Dec 13, 2019 at 4:02 PM 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. > > > > 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.
