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 <[email protected]> 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 <[email protected]> wrote:
>
>> On Wed, Nov 26, 2014 at 2:33 PM, svante karlsson <[email protected]> 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
