[
https://issues.apache.org/jira/browse/AVRO-1268?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexandre Normand updated AVRO-1268:
------------------------------------
Attachment: AVRO-1268.patch
Thanks for the comments Doug. I wasn't thinking of the API compatibility but I
revisited the changes after reading your comments and:
* I settled on leaving the addStringable in ReflectData while having the
default list of stringables in SpecificData. I think the use-case for
SpecificData would be for one of the default JDK classes that are stringable by
default or one could potentially write the schema to generate the
{{@Stringable}} annotation. Using a SpecificData#addStringable is probably not
a very common use case.
* I brought the PROP constants in ReflectData but marked them as deprecated
with the javadoc to redirected to SpecificData's constants.
* As for the {{StringablesRecord}} not needing to be checked in, I'm missing
something. The avdl files for that record are in {{java/compiler}} and
{{java/maven-plugin}} while the test for the {{SpecificDatumReader}} is in
{{java/avro}}. The generated class for that record won't show up in {{avro}}
since {{compiler}} and {{maven-plugin}} both depend on {{avro}} to have built
first. Also, the other specific record used in {{SpecificDatumReader}} is
{{FooBarSpecificRecord}} and that one is also in the source. What am I missing?
* I added a Specific test to {{Perf}} with the {{FooBarSpecificRecord}} (a
good reference since that's the one that was there prior to any of my changes).
I ran the modified {{Perf}} with and without my changes and it's not looking
great:
Before
{code}
Executing tests:
[FooBarSpecificRecordTest]
readTests:true
writeTests:true
cycles=800
test name time M entries/sec M bytes/sec
bytes/cycle
FooBarSpecificRecordTestRead: 16086 ms 1.036 60.413 1214805
FooBarSpecificRecordTestWrite: 8794 ms 1.895 110.505 1214805
{code}
After:
{code}
Executing tests:
[FooBarSpecificRecordTest]
readTests:true
writeTests:true
cycles=800
test name time M entries/sec M bytes/sec
bytes/cycle
FooBarSpecificRecordTestRead: 23937 ms 0.696 40.600 1214805
FooBarSpecificRecordTestWrite: 11369 ms 1.466 85.481 1214805
{code}
I'm adding the latest patch with the changes above. It's possible that the
performance hit could be less if I were to remove support for stringable
array/map elements and stringable keys and just keep the {{@java-class}}
support. I'd like not to do that though as this seems like a weird place to
leave things.
I would like if we could find a solution to mitigate the performance drop as I
think this is still a desirable feature.
Thoughts?
> Add java-class, java-key-class and java-element-class support for stringable
> types to SpecificData
> --------------------------------------------------------------------------------------------------
>
> Key: AVRO-1268
> URL: https://issues.apache.org/jira/browse/AVRO-1268
> Project: Avro
> Issue Type: Improvement
> Components: java
> Affects Versions: 1.7.4
> Reporter: Alexandre Normand
> Assignee: Alexandre Normand
> Priority: Minor
> Fix For: 1.7.5
>
> Attachments: AVRO-1268.patch, AVRO-1268.patch
>
>
> Stringable types are java classes that can be serialized through strings
> (which require a single string constructor and a valid toString()
> implementation). ReflectData currently has support from stringable types but
> it would be desirable to get this feature with SpecificData.
> The work involves changes to the SpecificCompiler (depends on {{@java-class}}
> support in AVRO-1267) to generate the specific sources with the proper java
> type as well as moving the ReflectDatumReader and ReflectDatumWriter to read
> the java-class/java-key-class and java-element-class properties.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
