Mailing-List: contact dev-help@avro.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@avro.apache.org
Date: Thu, 27 Nov 2014 16:39:12 +0000 (UTC)
From: "Niels Basjes (JIRA)" <jira@apache.org>
To: dev@avro.apache.org
Message-ID: <JIRA.12758248.1417102571000.35654.1417106352766@Atlassian.JIRA>
In-Reply-To: <JIRA.12758248.1417102571000@Atlassian.JIRA>
References: <JIRA.12758248.1417102571000@Atlassian.JIRA>
 <JIRA.12758248.1417102571280@arcas>
Subject: [jira] [Commented] (AVRO-1614) Always getting a value...
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


    [ https://issues.apache.org/jira/browse/AVRO-1614?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14227822#comment-14227822 ] 

Niels Basjes commented on 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:

{code}
public void setSomething(String value) {
    myStruct
            .getAlwaysFoo()
            .getAlwaysBar()
            .getAlwaysOne()
            .getAlwaysOther()
            .setSomething(value);
}
{code}

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.


> Always getting a value...
> -------------------------
>
>                 Key: AVRO-1614
>                 URL: https://issues.apache.org/jira/browse/AVRO-1614
>             Project: Avro
>          Issue Type: New Feature
>          Components: java
>            Reporter: Niels Basjes
>         Attachments: AVRO-1614-20141027-v1.patch
>
>
> Sometimes the Avro structure becomes deeply nested.
> If in such a scenario you want to be able to set a specific value deep in this tree you want to do this:
> {code}
> public void setSomething(String value) {
>     myStruct
>             .getFoo()
>             .getBar()
>             .getOne()
>             .getOther()
>             .setSomething(value);
> }
> {code}
> The 'problem' I ran into is that any of the 4 get methods can return a null value so the code I have to write is really huge.
> For every step in this method I have to build null checks and create the underlying instance if it is null.
> I already started writing helper methods to do this for parts of my tree.
> To solve this in a way that makes this code readable I came up with the following which I want to propose to you guys (before I start working on a patch).
> My idea is to generate a new 'get' method in addition to the existing normal get method for the regular instance of the class.
> So in addition to the 
> {code}
> public Foo getFoo() {
>     return foo;
> }
> {code}
> I propose to generate something like this as well in the cases where this is a type of structure that you may want to traverse as shown in the example.
> {code}
> public Foo getAlwaysFoo() {
>     if (foo == null) {
>         setFoo(Foo.newBuilder().build());
>     }
>     return foo;
> }
> {code}
> This way the automatically created instance immediately has all the defaults I have defined.
> Assuming this naming my code will be readable because it will look like this:
> {code}
> public void setSomething(String value) {
>     myStruct
>             .getAlwaysFoo()
>             .getAlwaysBar()
>             .getAlwaysOne()
>             .getAlwaysOther()
>             .setSomething(value);
> }
> {code}


--
This message was sent by Atlassian JIRA
(v6.3.4#6332)