[
https://issues.apache.org/jira/browse/AVRO-1614?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14232827#comment-14232827
]
Niels Basjes commented on AVRO-1614:
------------------------------------
@[~cutting]:
- Good idea to add additional tests to validate "builder" and "Builder". I'll
also be adding "builderBuilder", "value" and "this" to ensure we covered all
the edge cases.
- While making this I also found a lot of whitespaces changed. The main cause
is that some of the files (the Player.java files) are generated and simply
adding this feature changed those files a lot. Because I was already impacting
those files so much I chose to kick all the trailing spaces in one go... which
you say is too much, ok.
I understand the downside of this choice so I'll create a patch with the lowest
possible whitespace changes. Shall I create a new issue afterwards to clean
this up (I really like clean code!)?
- I don't quite understand the point regarding the tests. I put them under
lang/java/ipc because there the compiler is available and can generate java
code from the schema definitions. My tests are intended to validate that the
generated code behaves as intended (I'm actually unit testing the code
generated by the compiler). Putting them under ipc seemed like the best and
easiest place. To avoid conflicts with existing testing code I added a new idl
that resides in it's own package: org.apache.avro.test.http. So did I put the
tests I added in the right place? If not, what is the right place?
> 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
> Labels: java
> Attachments: AVRO-1614-20141027-v1.patch,
> AVRO-1614-20141201-v2.patch, AVRO-1614-20141202-v3.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)
