You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@avro.apache.org by "Jeff Hodges (JIRA)" <ji...@apache.org> on 2010/04/28 09:36:39 UTC
[jira] Created: (AVRO-531) ruby impl should produce better errors
on "flattened" schemas in fields
ruby impl should produce better errors on "flattened" schemas in fields
-----------------------------------------------------------------------
Key: AVRO-531
URL: https://issues.apache.org/jira/browse/AVRO-531
Project: Avro
Issue Type: Improvement
Components: ruby
Affects Versions: 1.3.2
Reporter: Jeff Hodges
Assignee: Jeff Hodges
The "flattened" schemas of fields that look like
{code}
"request": [
{ "name": "id", "type": "array", "items": "long" }
],
{code}
that are supposed to be
{code}
"request": [
{ "name": "id", "type": {"type": "array", "items": "long" }}
],
{code}
should have way better errors associated with them. Basically, we should check record types for things other than "default", "doc", "name", "type" and raise a specific error if they are seen.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Issue Comment Edited: (AVRO-531) ruby impl should produce
better errors on "flattened" schemas in fields
Posted by "Jeff Hodges (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/AVRO-531?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12861715#action_12861715 ]
Jeff Hodges edited comment on AVRO-531 at 4/28/10 4:03 AM:
-----------------------------------------------------------
Note that we can't allow for this flattening on most types!
This is unintuitive but allowing them all to be parsed as "flattened" leads to other problems. Say we mean to define a FileMode type for the first time in the request field like so:
{code}
{"name": "mode", "type":{"name":"FileMode", "type": "enum", "symbols": ["w", "r"] }
{code}
but "flatten" the definition like the "bad" protocol given:
{code}
{"name": "mode", "type": "enum", "symbols": ["w", "r"]}
{code}
This second schema is weird! We have the term "name" being overloaded! In the first one, we have a field named "mode" that takes a type named "FileMode" (remember that enums require names!). In the second one we have a field named "mode" and then some stuff that could be creating an enum named "mode" but really is just incomplete!
This behavior is slightly confusing when dealing with array and map types, but is consistent with the necessity to "nest" the named types enum, fixed, record, error and, of course, user-defined types
Really, this problem is because people (like my fine coworkers!) are expecting types to behave like the "simple" versions of primitive types (e.g. "string" instead of {"type": "string"}) when really they are much more than that! Hell, I've had to work on that myself!
So, again, we can't allow for this flattening because it is even more confusing than allowing it! Ugh!
was (Author: jmhodges):
Note that we can't allow for this flattening on most types!
This is unintuitive but allowing them all to be parsed as "flattened" leads to other problems. Say we mean to define a FileMode type for the first time in the request field like so:
{code}
{"name": "mode", "type":{"name":"FileMode", "type": "enum", "symbols": ["w", "r"] }
{code}
but "flatten" the definition like the "bad" protocol given:
{code}
{"name": "mode", "type": "enum", "symbols": ["w", "r"]}
{code}
This second schema is weird! We have the term "name" being overloaded! In the first one, we have a field named "mode" that takes a type named "FileMode" (remember that enum's require names!). In the second one we have a field named "mode" and then some stuff that could be creating an enum named "mode" but really is just incomplete!
This behavior is slightly confusing when dealing with array and map types, but is consistent with the necessity to "nest" the named types enum, fixed, record, error and, of course, user-defined types
Really, this problem is because people (like my fine coworkers!) are expecting types to behave like the "simple" versions of primitive types (e.g. "string" instead of {"type": "string"}) when really they are much more than that! Hell, I've had to work on that myself!
So, again, we can't allow for this flattening because it is even more confusing than allowing it! Ugh!
> ruby impl should produce better errors on "flattened" schemas in fields
> -----------------------------------------------------------------------
>
> Key: AVRO-531
> URL: https://issues.apache.org/jira/browse/AVRO-531
> Project: Avro
> Issue Type: Improvement
> Components: ruby
> Affects Versions: 1.3.2
> Reporter: Jeff Hodges
> Assignee: Jeff Hodges
>
> The "flattened" schemas of fields that look like
> {code}
> "request": [
> { "name": "id", "type": "array", "items": "long" }
> ],
> {code}
> that are supposed to be
> {code}
> "request": [
> { "name": "id", "type": {"type": "array", "items": "long" }}
> ],
> {code}
> should have way better errors associated with them. Basically, we should check record types for things other than "default", "doc", "name", "type" and raise a specific error if they are seen.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (AVRO-531) ruby impl should produce better errors
on "flattened" schemas in fields
Posted by "Jeff Hodges (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/AVRO-531?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12861715#action_12861715 ]
Jeff Hodges commented on AVRO-531:
----------------------------------
Note that we can't allow for this flattening on most types!
This is unintuitive but allowing them all to be parsed as "flattened" leads to other problems. Say we mean to define a FileMode type for the first time in the request field like so:
{code}
{"name": "mode", "type":{"name":"FileMode", "type": "enum", "symbols": ["w", "r"] }
{code}
but "flatten" the definition like the "bad" protocol given:
{code}
{"name": "mode", "type": "enum", "symbols": ["w", "r"]}
{code}
This second schema is weird! We have the term "name" being overloaded! In the first one, we have a field named "mode" that takes a type named "FileMode" (remember that enum's require names!). In the second one we have a field named "mode" and then some stuff that could be creating an enum named "mode" but really is just incomplete!
This behavior is slightly confusing when dealing with array and map types, but is consistent with the necessity to "nest" the named types enum, fixed, record, error and, of course, user-defined types
Really, this problem is because people (like my fine coworkers!) are expecting types to behave like the "simple" versions of primitive types (e.g. "string" instead of {"type": "string"}) when really they are much more than that! Hell, I've had to work on that myself!
So, again, we can't allow for this flattening because it is even more confusing than allowing it! Ugh!
> ruby impl should produce better errors on "flattened" schemas in fields
> -----------------------------------------------------------------------
>
> Key: AVRO-531
> URL: https://issues.apache.org/jira/browse/AVRO-531
> Project: Avro
> Issue Type: Improvement
> Components: ruby
> Affects Versions: 1.3.2
> Reporter: Jeff Hodges
> Assignee: Jeff Hodges
>
> The "flattened" schemas of fields that look like
> {code}
> "request": [
> { "name": "id", "type": "array", "items": "long" }
> ],
> {code}
> that are supposed to be
> {code}
> "request": [
> { "name": "id", "type": {"type": "array", "items": "long" }}
> ],
> {code}
> should have way better errors associated with them. Basically, we should check record types for things other than "default", "doc", "name", "type" and raise a specific error if they are seen.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.