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
>
