On Fri, 13 Dec 2019 at 16:56, Ryan Skraba <r...@skraba.com> wrote:
> 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!
>
That's a really good point that I hadn't considered, thanks!
Of course, theoretically the spec already has that issue AFAICS, because
it's legal to have a schema that's just "null", I think, although that's
not very useful!
I think when I implement my streaming code, if the size of the encoded
value is zero, I'll choose to return at most one value from the stream, and
thus avoid that particular gotcha.
The question of "are zero things allowed" aso arises for enums (it's not
clear if it's allowed to have an enum with no symbols) and fixed (it's not
clear if it's allowed to have a zero-size fixed type). Both would probably
be worth clearing up in the spec, I think.
cheers,
rog.
> 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.
>
