I uploaded a patch for AVRO-1614 and AVRO-1616 (just an update to the
.gitignore).
It seems that there is no automatic pickup by Jenkins configured (like with
Hadoop and HBase).
How do I proceed in getting your feedback on these patches and getting them
reviewed and if possible comitted?
Thanks.
Niels Basjes
On Mon, Dec 1, 2014 at 6:05 PM, Niels Basjes <ni...@basjes.nl> wrote:
> Hi,
>
> I realized over the weekend that the Builder instances do support an
> 'incomplete' schema and this is validated at the time the build() is called.
> Based upon that I redid the patch today so that in a Builder in addition
> to the actual value of a field there is now also a "Builder" field for that
> field possible.
> If that is used then you can have the incomplete form of the sub-schema in
> a Builder.
> So for any Builder instance there is a getFooBuilder() that either returns
> the existing or creates a new Builder instance for the Foo field if such a
> builder is supported.
>
> As a consequence:
> - schema validation is postponed until the actual build() is called.
> - for the fields where this Builder is used the actual build() call
> becomes recursive.
>
> So in my testing code I can now do this:
>
>
> * Measurement.Builder measurementBuilder = Measurement.newBuilder();*
>
> * measurementBuilder*
> * .getTransportBuilder()*
> * .getConnectionBuilder()*
> * .getNetworkConnectionBuilder()*
> * .setNetworkAddress("127.0.0.1")*
> * .setNetworkType(NetworkType.IPv4);*
>
> * Measurement measurement = measurementBuilder.build();*
>
> Open question: I have not seen unit tests that validate the generated Java
> code yet. How to approach this?
>
> Niels Basjes
>
>
> On Thu, Nov 27, 2014 at 5:37 PM, Niels Basjes <ni...@basjes.nl> wrote:
>
>> Hi,
>>
>> To see how it would work I simply wrote the patch and played in my
>> environment with the effects on the generated Java code.
>> [ I created a Jira issue and attached this draft patch to it:
>> https://issues.apache.org/jira/browse/AVRO-1614 ]
>>
>> The idea works but I also found that for my usecase it is not very
>> pleasant to work with.
>>
>> Assume this example again:
>>
>> public void setSomething(String value) {
>> myStruct
>> .getAlwaysFoo()
>> .getAlwaysBar()
>> .getAlwaysOne()
>> .getAlwaysOther()
>> .setSomething(value);
>> }
>>
>> The main problem is that in order to do .getAlwaysOne() I MUST define
>> ALL fields of that type with a default value.
>> What I don;t like about that is that I want the schema definition to
>> enforce the fact that some fields are mandatory.
>> By adding a default value to 'everything' I lose that capability of AVRO
>> ... which I don't want.
>>
>> At this point in time the only workaround this (for me major) issue is by
>> introducing something where I can do something like having a 'tree of
>> incomplete Builders' and when I say 'build()' to the top one it will build
>> the entire tree.
>>
>> Any thoughts?
>> Do you guy think there is a need/usecase for this idea (so I leave the
>> issue open) or shall I simply close AVRO-1614 with a 'Won't fix'?
>>
>> Niels Basjes
>>
>>
>>
>> On Thu, Nov 27, 2014 at 1:37 AM, Doug Cutting <cutt...@apache.org> wrote:
>>
>>> On Wed, Nov 26, 2014 at 2:33 PM, svante karlsson <s...@csi.se> wrote:
>>> > I'm not sure that works for avro where null is used for an optional
>>> field.
>>>
>>> It should work. If it doesn't, it's a bug. For example:
>>>
>>> record Foo {
>>> union {string, null} name = "default";
>>> }
>>>
>>> record Bar {
>>> union {Foo, null} foo = {"name" = "non-default"};
>>> }
>>>
>>> Default values in IDL are JSON format.
>>>
>>> Doug
>>>
>>
>>
>>
>> --
>> Best regards / Met vriendelijke groeten,
>>
>> Niels Basjes
>>
>
>
>
> --
> Best regards / Met vriendelijke groeten,
>
> Niels Basjes
>
--
Best regards / Met vriendelijke groeten,
Niels Basjes
