avro-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Doug Cutting (JIRA)" <j...@apache.org>
Subject [jira] Commented: (AVRO-22) Kill anonymous records or fix GenericDatumReader
Date Wed, 27 May 2009 17:19:45 GMT

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

Doug Cutting commented on AVRO-22:

> The only lingering issue I have is wrt the changes Doug checked in, which breaks the
symmetry between parse() and toString(). 

To be clear, your concern is that one can programmatically create a schema whose toString()
cannot be read?  Isn't this true regardless of anonymous records, since we don't check for
name conflicts when we create a compound schema?  This seems like a separate issue from whether
parse permits anonymous records.  I think we all agree it should not, and that's the change
that was committed for this issue.  If we want to make it impossible to construct a schema
that toString() cannot write and/or parse cannot read, we should perhaps address that in a
separate issue.

So can we re-close this issue?  To my thinking, this was a specification question: are anonymous
records permissible in JSON schemas?  If the Java implementation's toString() generates unparseable
strings, that's a bug in Java, not a specification issue.

> Kill anonymous records or fix GenericDatumReader
> ------------------------------------------------
>                 Key: AVRO-22
>                 URL: https://issues.apache.org/jira/browse/AVRO-22
>             Project: Avro
>          Issue Type: Bug
>          Components: spec
>            Reporter: Raymie Stata
>            Assignee: Doug Cutting
>             Fix For: 1.0
> Anonymous record names are a pain, can we get rid of them?
> If not, I think I noticed a bug in GenericDatumReader.resolveExpected:
> {noformat}
>      if (branch.getType() == Type.RECORD) {
>        String name = branch.getName();
>        if (name == null || name.equals(actual.getName()))
>          return branch;
>      } else
>        return branch;
> {noformat}
> This doesn't seem to require that _both_ are null to match: if the name of {{branch}}
is null and the name {{actual}} is not, then we get a match, which I think is a bug.
> But again, let's just get rid of null names.

This message is automatically generated by JIRA.
You can reply to this email to add a comment to the issue online.

View raw message