[jira] [Updated] (AVRO-1633) Add additional setXxx(Builder) method to make user code more readable.
[
https://issues.apache.org/jira/browse/AVRO-1633?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Niels Basjes updated AVRO-1633:
---
Description:
The currently generated code contains these two methods for the Builder
instances (code sample was simplified):
{code}public Request.Builder setConnection(NetworkConnection value)
public Request.Builder setConnectionBuilder(NetworkConnection.Builder
value){code}
My proposal: Add in addition the method:
{code}public Request.Builder setConnection(NetworkConnection.Builder
value){code}
Advantage:
You can do {{.setConnection(something)}} and pass either a
{{NetworkConnection}} or a {{NetworkConnection.Builder}}.
Disadvantage:
Explicitly setting a {{null}} will trigger a Multiple implementations error
and as such will need an explicit typecast.
This may be considered breaking backward compatibility!
was:
The currently generated code contains these two methods for the Builder
instances (code sample was simplified):
{code}public Request.Builder setConnection(NetworkConnection value)
public Request.Builder setConnectionBuilder(NetworkConnection.Builder
value){code}
My proposal: Add in addition the method:
{code}public Request.Builder setConnection(NetworkConnection.Builder
value){code}
Advantage:
You can do {{.setConnection(something)}} and pass either a
{{NetworkConnection}} or a {{NetworkConnection.Builder}}.
Disadvantage:
Explicitly setting a {{null}} will trigger a Multiple implementations error
and as such will need an explicit typecast.
Add additional setXxx(Builder) method to make user code more readable.
--
Key: AVRO-1633
URL: https://issues.apache.org/jira/browse/AVRO-1633
Project: Avro
Issue Type: Improvement
Components: java
Affects Versions: 1.8.0
Reporter: Niels Basjes
Assignee: Niels Basjes
Fix For: 1.8.0
Attachments: AVRO-1633-2015-01-20-v1.patch
The currently generated code contains these two methods for the Builder
instances (code sample was simplified):
{code}public Request.Builder setConnection(NetworkConnection value)
public Request.Builder setConnectionBuilder(NetworkConnection.Builder
value){code}
My proposal: Add in addition the method:
{code}public Request.Builder setConnection(NetworkConnection.Builder
value){code}
Advantage:
You can do {{.setConnection(something)}} and pass either a
{{NetworkConnection}} or a {{NetworkConnection.Builder}}.
Disadvantage:
Explicitly setting a {{null}} will trigger a Multiple implementations error
and as such will need an explicit typecast.
This may be considered breaking backward compatibility!
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (AVRO-1633) Add additional setXxx(Builder) method to make user code more readable.
[
https://issues.apache.org/jira/browse/AVRO-1633?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Niels Basjes updated AVRO-1633:
---
Description:
The currently generated code contains these two methods for the Builder
instances (code sample was simplified):
{code}public Request.Builder setConnection(NetworkConnection value)
public Request.Builder setConnectionBuilder(NetworkConnection.Builder
value){code}
My proposal: Add in addition the method:
{code}public Request.Builder setConnection(NetworkConnection.Builder
value){code}
Advantage:
* You can do {{.setConnection(something)}} and pass either a
{{NetworkConnection}} or a {{NetworkConnection.Builder}}.
* User code becomes a bit more readable.
Disadvantages:
* Explicitly setting a {{null}} will trigger a Multiple implementations error
and as such will need an explicit typecast.
** _This may be considered breaking backward compatibility!_
To solve this you must do either this:
{code}.setConnection((NetworkConnection)null){code}
or this {code}
NetworkConnection nc = null;
...
.setConnection(nc){code}
was:
The currently generated code contains these two methods for the Builder
instances (code sample was simplified):
{code}public Request.Builder setConnection(NetworkConnection value)
public Request.Builder setConnectionBuilder(NetworkConnection.Builder
value){code}
My proposal: Add in addition the method:
{code}public Request.Builder setConnection(NetworkConnection.Builder
value){code}
Advantage:
You can do {{.setConnection(something)}} and pass either a
{{NetworkConnection}} or a {{NetworkConnection.Builder}}.
Disadvantage:
Explicitly setting a {{null}} will trigger a Multiple implementations error
and as such will need an explicit typecast.
This may be considered breaking backward compatibility!
Add additional setXxx(Builder) method to make user code more readable.
--
Key: AVRO-1633
URL: https://issues.apache.org/jira/browse/AVRO-1633
Project: Avro
Issue Type: Improvement
Components: java
Affects Versions: 1.8.0
Reporter: Niels Basjes
Assignee: Niels Basjes
Fix For: 1.8.0
Attachments: AVRO-1633-2015-01-20-v1.patch
The currently generated code contains these two methods for the Builder
instances (code sample was simplified):
{code}public Request.Builder setConnection(NetworkConnection value)
public Request.Builder setConnectionBuilder(NetworkConnection.Builder
value){code}
My proposal: Add in addition the method:
{code}public Request.Builder setConnection(NetworkConnection.Builder
value){code}
Advantage:
* You can do {{.setConnection(something)}} and pass either a
{{NetworkConnection}} or a {{NetworkConnection.Builder}}.
* User code becomes a bit more readable.
Disadvantages:
* Explicitly setting a {{null}} will trigger a Multiple implementations
error and as such will need an explicit typecast.
** _This may be considered breaking backward compatibility!_
To solve this you must do either this:
{code}.setConnection((NetworkConnection)null){code}
or this {code}
NetworkConnection nc = null;
...
.setConnection(nc){code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (AVRO-1633) Add additional setXxx(Builder) method to make user code more readable.
[
https://issues.apache.org/jira/browse/AVRO-1633?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Niels Basjes updated AVRO-1633:
---
Status: Patch Available (was: Open)
Hi [~cutting],
Please classify this as either _wanted_ or _unwanted_ because of this backward
compatibility point when setting a 'null' directly.
Thanks.
Add additional setXxx(Builder) method to make user code more readable.
--
Key: AVRO-1633
URL: https://issues.apache.org/jira/browse/AVRO-1633
Project: Avro
Issue Type: Improvement
Components: java
Affects Versions: 1.8.0
Reporter: Niels Basjes
Assignee: Niels Basjes
Fix For: 1.8.0
Attachments: AVRO-1633-2015-01-20-v1.patch
The currently generated code contains these two methods for the Builder
instances (code sample was simplified):
{code}public Request.Builder setConnection(NetworkConnection value)
public Request.Builder setConnectionBuilder(NetworkConnection.Builder
value){code}
My proposal: Add in addition the method:
{code}public Request.Builder setConnection(NetworkConnection.Builder
value){code}
Advantage:
* You can do {{.setConnection(something)}} and pass either a
{{NetworkConnection}} or a {{NetworkConnection.Builder}}.
* User code becomes a bit more readable.
Disadvantages:
* Explicitly setting a {{null}} will trigger a Multiple implementations
error and as such will need an explicit typecast.
** _This may be considered breaking backward compatibility!_
To solve this you must do either this:
{code}.setConnection((NetworkConnection)null){code}
or this {code}
NetworkConnection nc = null;
...
.setConnection(nc){code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (AVRO-1633) Add additional setXxx(Builder) method to make user code more readable.
[
https://issues.apache.org/jira/browse/AVRO-1633?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Niels Basjes updated AVRO-1633:
---
Attachment: AVRO-1633-2015-01-20-v1.patch
The patch that implements the proposal.
Add additional setXxx(Builder) method to make user code more readable.
--
Key: AVRO-1633
URL: https://issues.apache.org/jira/browse/AVRO-1633
Project: Avro
Issue Type: Improvement
Components: java
Affects Versions: 1.8.0
Reporter: Niels Basjes
Assignee: Niels Basjes
Fix For: 1.8.0
Attachments: AVRO-1633-2015-01-20-v1.patch
The currently generated code contains these two methods for the Builder
instances (code sample was simplified):
{code}public Request.Builder setConnection(NetworkConnection value)
public Request.Builder setConnectionBuilder(NetworkConnection.Builder
value){code}
My proposal: Add in addition the method:
{code}public Request.Builder setConnection(NetworkConnection.Builder
value){code}
Advantage:
You can do {{.setConnection(something)}} and pass either a
{{NetworkConnection}} or a {{NetworkConnection.Builder}}.
Disadvantage:
Explicitly setting a {{null}} will trigger a Multiple implementations error
and as such will need an explicit typecast.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (AVRO-1625) Adding Microsoft C# Implementation to the project
[ https://issues.apache.org/jira/browse/AVRO-1625?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14284068#comment-14284068 ] Markus Weimer commented on AVRO-1625: - FWIW, we are using this library in REEF, [REEF-51], specifically. It would be awesome to see this within Apache Avro. Adding Microsoft C# Implementation to the project - Key: AVRO-1625 URL: https://issues.apache.org/jira/browse/AVRO-1625 Project: Avro Issue Type: New Feature Components: csharp Reporter: Alexey Orlov In April 2014 Microsoft released to the public its own C# implementation of Avro. The code is completely new. The reasoning for the project was to overcome the limitations of C# implementation available as a component of Apache project at the time we have commenced the effort (early 2013). In particular: - Low performance - Missing support of serialization using Reflection Our implementation is called Microsoft Avro Library and available here https://hadoopsdk.codeplex.com/wikipage?title=Avro%20Library (together with the code) Throughout 2014 we have released some updates, fixed bugs, added a feature and now would like to start a conversation about contributing our library to the project. Doug Cutting suggested I start a Jira issue for this conversation, so I’m following the advice (see http://mail-archives.apache.org/mod_mbox/avro-dev/201406.mbox/%3c50937b33cdf7ca46afcc1f1d04c6551a0a01b...@db3ex14mbxc327.europe.corp.microsoft.com%3e) Some background information on today’s state of the library: - The library supports binary serialization only - RPC support is NOT implemented - The library is compiled vs Microsoft .NET Framework 4.0. We have NOT tested it on other platforms (e.g. with Mono). And about me. I’m a Microsoft employee and Program Manager responsible for the project. Looking forward getting the feedback. Thank you, Alexey -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AVRO-1634) Clear all fields / Reset all fields to default value on Record template
[ https://issues.apache.org/jira/browse/AVRO-1634?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maulik Gandhi updated AVRO-1634: Description: As a developer, it would be nice to have a feature, API which will expose the functionality of clearing all fields on Record or set them to default value if the attribute has default value, so that the consumers do not have to write custom methods for the use case described before. Also when a Builder pattern is used for creating Objects from Record, builders can be re-used, thus reducing heap memory usage. Discussion around same topic can be found in [archives | http://mail-archives.apache.org/mod_mbox/avro-user/201501.mbox/%3CCALEq1Z8M8m1JH=tuiaktjjuteqbgh-fqtb0upp4hu_pksc-...@mail.gmail.com%3E] was: As a developer, it would be nice to have a feature, API which will expose the functionality of clearing all fields on Record or set them to default value if the attribute has default value, so that the consumers do not have to write custom methods for the use case described before. Also when a Builder pattern is used for creating Objects from Record, builders can be re-used, thus reducing heap memory usage. Clear all fields / Reset all fields to default value on Record template --- Key: AVRO-1634 URL: https://issues.apache.org/jira/browse/AVRO-1634 Project: Avro Issue Type: New Feature Components: java Reporter: Maulik Gandhi Priority: Minor As a developer, it would be nice to have a feature, API which will expose the functionality of clearing all fields on Record or set them to default value if the attribute has default value, so that the consumers do not have to write custom methods for the use case described before. Also when a Builder pattern is used for creating Objects from Record, builders can be re-used, thus reducing heap memory usage. Discussion around same topic can be found in [archives | http://mail-archives.apache.org/mod_mbox/avro-user/201501.mbox/%3CCALEq1Z8M8m1JH=tuiaktjjuteqbgh-fqtb0upp4hu_pksc-...@mail.gmail.com%3E] -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (AVRO-1634) Clear all fields / Reset all fields to default value on Record template
[ https://issues.apache.org/jira/browse/AVRO-1634?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14284178#comment-14284178 ] Maulik Gandhi commented on AVRO-1634: - * I was thinking of making a change in Velocity template: [Record | https://github.com/apache/avro/blob/branch-1.7/lang/java/compiler/src/main/velocity/org/apache/avro/compiler/specific/templates/java/classic/record.vm] * I will post a patch, once I have things working on. Clear all fields / Reset all fields to default value on Record template --- Key: AVRO-1634 URL: https://issues.apache.org/jira/browse/AVRO-1634 Project: Avro Issue Type: New Feature Components: java Reporter: Maulik Gandhi Priority: Minor As a developer, it would be nice to have a feature, API which will expose the functionality of clearing all fields on Record or set them to default value if the attribute has default value, so that the consumers do not have to write custom methods for the use case described before. Also when a Builder pattern is used for creating Objects from Record, builders can be re-used, thus reducing heap memory usage. Discussion around same topic can be found in [archives | http://mail-archives.apache.org/mod_mbox/avro-user/201501.mbox/%3CCALEq1Z8M8m1JH=tuiaktjjuteqbgh-fqtb0upp4hu_pksc-...@mail.gmail.com%3E] -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (AVRO-1634) Clear all fields / Reset all fields to default value on Record template
Maulik Gandhi created AVRO-1634: --- Summary: Clear all fields / Reset all fields to default value on Record template Key: AVRO-1634 URL: https://issues.apache.org/jira/browse/AVRO-1634 Project: Avro Issue Type: New Feature Components: java Reporter: Maulik Gandhi Priority: Minor As a developer, it would be nice to have a feature, API which will expose the functionality of clearing all fields on Record or set them to default value if the attribute has default value, so that the consumers do not have to write custom methods for the use case described before. Also when a Builder pattern is used for creating Objects from Record, builders can be re-used, thus reducing heap memory usage. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (AVRO-680) Allow for non-string keys
[
https://issues.apache.org/jira/browse/AVRO-680?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14284694#comment-14284694
]
Sachin Goyal commented on AVRO-680:
---
[~cutting], can you help decide what would be a better approach to go here?
I think non-string keys is a useful feature and we should get it to work either
by my patch or previous support (if it covers all the cases).
Your opinion would help.
Allow for non-string keys
-
Key: AVRO-680
URL: https://issues.apache.org/jira/browse/AVRO-680
Project: Avro
Issue Type: Improvement
Affects Versions: 1.7.6, 1.7.7
Reporter: Jeremy Hanna
Attachments: AVRO-680.patch, AVRO-680.patch, PERF_8000_cycles.zip,
isMap_Call_Hierarchy.png, non_string_map_keys.zip, non_string_map_keys2.zip,
non_string_map_keys3.zip, non_string_map_keys4.patch,
non_string_map_keys5.patch, non_string_map_keys6.patch,
non_string_map_keys7.patch, non_string_map_perf.txt,
non_string_map_perf2.txt, original_perf.txt
Based on an email thread back in April, Doug Cutting proposed a possible
solution for having non-string keys:
Stu Hood wrote:
I can understand the reasoning behind AVRO-9, but now I need to look for an
alternative to a 'map' that will allow me to store an association of bytes
keys to values.
A map of Foo has the same binary format as an array of records, each
with a string field and a Foo field. So an application can use an array
schema similar to this to represent map-like structures with, e.g.,
non-string keys.
Perhaps we could establish standard properties that indicate that a
given array of records should be represented in a map-like way if
possible? E.g.,:
{type: array, isMap: true, items: {type:record, ...}}
Doug
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
