[jira] [Created] (AVRO-1511) Add Support for Immutable Array and Map Fields
Sharmarke Aden created AVRO-1511: Summary: Add Support for Immutable Array and Map Fields Key: AVRO-1511 URL: https://issues.apache.org/jira/browse/AVRO-1511 Project: Avro Issue Type: Improvement Components: java Affects Versions: 1.7.6 Reporter: Sharmarke Aden Assignee: Doug Cutting Priority: Minor Sometimes you want to pass your Avro bean around to various systems in your infrastructure and don't want anyone to alter the state of the bean. Currently one can prevent changes to various field by preventing the generation of setter methods but for array and map fields one can still get the array/map and perform mutating operations (i.e. add new element a list). -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (AVRO-1511) Add Support for Immutable Array and Map Fields
[ https://issues.apache.org/jira/browse/AVRO-1511?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sharmarke Aden updated AVRO-1511: - Description: Sometimes you want to pass your Avro bean around to various systems in your infrastructure and don't want anyone to alter the state of the bean. Currently one can prevent changes to various field by preventing the generation of setter methods but for array and map fields one can still get the array/map and perform mutating operations (i.e. add new element to the list). was: Sometimes you want to pass your Avro bean around to various systems in your infrastructure and don't want anyone to alter the state of the bean. Currently one can prevent changes to various field by preventing the generation of setter methods but for array and map fields one can still get the array/map and perform mutating operations (i.e. add new element a list). Add Support for Immutable Array and Map Fields -- Key: AVRO-1511 URL: https://issues.apache.org/jira/browse/AVRO-1511 Project: Avro Issue Type: Improvement Components: java Affects Versions: 1.7.6 Reporter: Sharmarke Aden Assignee: Doug Cutting Priority: Minor Sometimes you want to pass your Avro bean around to various systems in your infrastructure and don't want anyone to alter the state of the bean. Currently one can prevent changes to various field by preventing the generation of setter methods but for array and map fields one can still get the array/map and perform mutating operations (i.e. add new element to the list). -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (AVRO-1245) Add Merging Functionality to Generated Builders
[
https://issues.apache.org/jira/browse/AVRO-1245?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13657519#comment-13657519
]
Sharmarke Aden commented on AVRO-1245:
--
It would be nice to use fluent method chaining to specify merge conditions
though calling newBuilder(thirdPartyRecord) first wouldn't be as performant.
Perhaps we can do something like this and delay merging until the end:
{code}
User.newBuilder()
.ignoreNullValues()
.ignoreEmptyStrings()
.merge(thirdPartyRecord)
.build();
{code}
Of course doing something like the above would require keeping state
information in the builder.
[~cutting],
Any thoughts on this feature?
Add Merging Functionality to Generated Builders
---
Key: AVRO-1245
URL: https://issues.apache.org/jira/browse/AVRO-1245
Project: Avro
Issue Type: Improvement
Components: java
Affects Versions: 1.7.3
Environment: Linux Mint 32-bit, Java 7, Avro 1.7.3
Reporter: Sharmarke Aden
Priority: Minor
Suppose I have a record with the following schema and default values:
{code}
{
type: record,
namespace: test,
name: User,
fields: [
{
name: user,
type: [null, string],
default: null
},
{
name: privacy,
type: [
{
type: enum,
name: Privacy,
namespace: test,
symbols: [Public, Private]
},
null
],
default: Private
}
]
}
{code}
Now suppose I have a record supplied to me by a third party whose privacy
field value is null. Currently if you call
Builder.newBuilder(thirdPartyRecord) it simply creates a new record with
same values as the source record (privacy is null in the newly created
builder).
It's very important that the privacy value be set and so ideally I would like
to perform a merge to mitigate any issues with default values being absent in
the source record. I would like to propose that a new enhancement be added to
the Builder to support merging of a source record to a new record. Perhaps
something like this:
{code}
// recordWithoutDefaults record passed in.
User.Builder builder = User.newBuilder();
//ignore null values in the source record if the schema has a default
//value for the field
boolean ignoreNull = true;
//ignore empty string values in the source record for string field
//types with default field values
boolean ignoreEmptyString = true;
//while this is simple and useful in my use-case perhaps there's a
//better/refined way of supporting veracious merging models
builder.merge(recordWithoutDefaults, ignoreNull, ignoreEmptyString);
{code}
--
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
[jira] [Created] (AVRO-1245) Add Merging Functionality to Generated Builders
Sharmarke Aden created AVRO-1245:
Summary: Add Merging Functionality to Generated Builders
Key: AVRO-1245
URL: https://issues.apache.org/jira/browse/AVRO-1245
Project: Avro
Issue Type: Bug
Components: java
Affects Versions: 1.7.3
Environment: Linux Mint 32-bit, Java 7, Avro 1.7.3
Reporter: Sharmarke Aden
Suppose I have a record with the following schema and default values:
{code}
{
type: record,
namespace: test,
name: User,
fields: [
{
name: user,
type: [null, string],
default: null
},
{
name: privacy,
type: [
{
type: enum,
name: Privacy,
namespace: test,
symbols: [Public, Private]
},
null
],
default: Private
}
]
}
{code}
Now suppose I have a record supplied to me by a third party whose privacy field
value is null. Currently if you call Builder.newBuilder(thirdPartyRecord) it
simply creates a new record with same values as the source record (privacy is
null in the newly created builder).
It's very important that the privacy value be set and so ideally I would like
to perform a merge to mitigate any issues with default values being absent in
the source record. I would like to propose that a new enhancement be added to
the Builder to support merging of a source record to a new record. Perhaps
something like this:
{code}
// recordWithoutDefaults record passed in.
User.Builder builder = User.newBuilder();
//ignore null values in the source record if the schema has a default
//value for the field
boolean ignoreNull = true;
//ignore empty string values in the source record for string field
//types with default field values
boolean ignoreEmptyString = true;
//while this is simple and useful in my use-case perhaps there's a
//better/refined way of supporting veracious merging models
builder.merge(recordWithoutDefaults, ignoreNull, ignoreEmptyString);
{code}
--
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
[jira] [Updated] (AVRO-1245) Add Merging Functionality to Generated Builders
[
https://issues.apache.org/jira/browse/AVRO-1245?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sharmarke Aden updated AVRO-1245:
-
Issue Type: Improvement (was: Bug)
Add Merging Functionality to Generated Builders
---
Key: AVRO-1245
URL: https://issues.apache.org/jira/browse/AVRO-1245
Project: Avro
Issue Type: Improvement
Components: java
Affects Versions: 1.7.3
Environment: Linux Mint 32-bit, Java 7, Avro 1.7.3
Reporter: Sharmarke Aden
Suppose I have a record with the following schema and default values:
{code}
{
type: record,
namespace: test,
name: User,
fields: [
{
name: user,
type: [null, string],
default: null
},
{
name: privacy,
type: [
{
type: enum,
name: Privacy,
namespace: test,
symbols: [Public, Private]
},
null
],
default: Private
}
]
}
{code}
Now suppose I have a record supplied to me by a third party whose privacy
field value is null. Currently if you call
Builder.newBuilder(thirdPartyRecord) it simply creates a new record with
same values as the source record (privacy is null in the newly created
builder).
It's very important that the privacy value be set and so ideally I would like
to perform a merge to mitigate any issues with default values being absent in
the source record. I would like to propose that a new enhancement be added to
the Builder to support merging of a source record to a new record. Perhaps
something like this:
{code}
// recordWithoutDefaults record passed in.
User.Builder builder = User.newBuilder();
//ignore null values in the source record if the schema has a default
//value for the field
boolean ignoreNull = true;
//ignore empty string values in the source record for string field
//types with default field values
boolean ignoreEmptyString = true;
//while this is simple and useful in my use-case perhaps there's a
//better/refined way of supporting veracious merging models
builder.merge(recordWithoutDefaults, ignoreNull, ignoreEmptyString);
{code}
--
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
[jira] [Created] (AVRO-1246) Add Support for Set Complex Type
Sharmarke Aden created AVRO-1246: Summary: Add Support for Set Complex Type Key: AVRO-1246 URL: https://issues.apache.org/jira/browse/AVRO-1246 Project: Avro Issue Type: New Feature Components: spec Affects Versions: 1.7.3 Environment: Linux Mint 32-bit, Java 7 Reporter: Sharmarke Aden Avro specification currently lacks support for set complex type. While this limitation can be mitigated by using array complex type in conjunction with post processing it would be nice if the specification supported a widely used/useful data structure. -- 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
[jira] [Created] (AVRO-1213) Dependency on Jetty Servlet API in IPC
Sharmarke Aden created AVRO-1213: Summary: Dependency on Jetty Servlet API in IPC Key: AVRO-1213 URL: https://issues.apache.org/jira/browse/AVRO-1213 Project: Avro Issue Type: Improvement Components: java Affects Versions: 1.7.2 Reporter: Sharmarke Aden Priority: Minor The compile scoped dependency on jetty servlet-api in the IPC pom file can be problematic if using Avro in a webapp environment. Would it be possible to make this dependency either optional or provided? Or maybe Avro modularize into sub-modules in such a way that desired features can be assembled piecemeal? -- 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
[jira] [Commented] (AVRO-1213) Dependency on Jetty Servlet API in IPC
[ https://issues.apache.org/jira/browse/AVRO-1213?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13507712#comment-13507712 ] Sharmarke Aden commented on AVRO-1213: -- Doug, I wasn't really sure in what capacity Jetty is used but looking at IPC code it looks like those jetty dependencies are needed down stream by those wishing to use IPC. Scott, I think you are right on them money. Ultimately what you want to do is break the IPC into Jetty and Netty sub-modules so they can become optional and allow of future growth with respect to adding new Server implementations (i.e. tomcat, vert.x, NodeJS, etc). Dependency on Jetty Servlet API in IPC -- Key: AVRO-1213 URL: https://issues.apache.org/jira/browse/AVRO-1213 Project: Avro Issue Type: Improvement Components: java Affects Versions: 1.7.2 Reporter: Sharmarke Aden Priority: Minor The compile scoped dependency on jetty servlet-api in the IPC pom file can be problematic if using Avro in a webapp environment. Would it be possible to make this dependency either optional or provided? Or maybe Avro modularize into sub-modules in such a way that desired features can be assembled piecemeal? -- 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
[jira] [Updated] (AVRO-1201) CLONE - GenericRecord.toString can produce invalid JSON
[
https://issues.apache.org/jira/browse/AVRO-1201?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sharmarke Aden updated AVRO-1201:
-
Attachment: vcs-diff4833874908267370412.patch
CLONE - GenericRecord.toString can produce invalid JSON
---
Key: AVRO-1201
URL: https://issues.apache.org/jira/browse/AVRO-1201
Project: Avro
Issue Type: Bug
Components: java
Affects Versions: 1.7.2
Reporter: Sharmarke Aden
Assignee: Jay Kreps
Attachments: avro-1201.patch, avro-1201.patch,
Avro-1201-TestCase.tar.gz, vcs-diff4833874908267370412.patch
The GenericData.toString method can produce invalid JSON. The problem is that
enums are printed without quotes, as in
{emum_field:a}
instead of
{enum_field:a}
--
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
[jira] [Commented] (AVRO-1201) CLONE - GenericRecord.toString can produce invalid JSON
[
https://issues.apache.org/jira/browse/AVRO-1201?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13501236#comment-13501236
]
Sharmarke Aden commented on AVRO-1201:
--
I am wondering if this patch is acceptable and will get committed.
CLONE - GenericRecord.toString can produce invalid JSON
---
Key: AVRO-1201
URL: https://issues.apache.org/jira/browse/AVRO-1201
Project: Avro
Issue Type: Bug
Components: java
Affects Versions: 1.7.2
Reporter: Sharmarke Aden
Assignee: Jay Kreps
Attachments: avro-1201.patch, avro-1201.patch,
Avro-1201-TestCase.tar.gz
The GenericData.toString method can produce invalid JSON. The problem is that
enums are printed without quotes, as in
{emum_field:a}
instead of
{enum_field:a}
--
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
[jira] [Commented] (AVRO-1207) Add Mojo Tests to the Maven Plugin
[ https://issues.apache.org/jira/browse/AVRO-1207?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13500015#comment-13500015 ] Sharmarke Aden commented on AVRO-1207: -- Did minor comments and code clean up. Add Mojo Tests to the Maven Plugin -- Key: AVRO-1207 URL: https://issues.apache.org/jira/browse/AVRO-1207 Project: Avro Issue Type: Improvement Components: java Affects Versions: 1.7.2 Reporter: Sharmarke Aden Assignee: Sharmarke Aden Priority: Minor Fix For: 1.7.3 Attachments: vcs-diff5497937809969069066.patch, vcs-diff6800257181085963461.patch The plugin Mojos currently don't have tests. -- 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
[jira] [Updated] (AVRO-1207) Add Mojo Tests to the Maven Plugin
[ https://issues.apache.org/jira/browse/AVRO-1207?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sharmarke Aden updated AVRO-1207: - Attachment: vcs-diff5497937809969069066.patch Add Mojo Tests to the Maven Plugin -- Key: AVRO-1207 URL: https://issues.apache.org/jira/browse/AVRO-1207 Project: Avro Issue Type: Improvement Components: java Affects Versions: 1.7.2 Reporter: Sharmarke Aden Assignee: Sharmarke Aden Priority: Minor Fix For: 1.7.3 Attachments: vcs-diff5497937809969069066.patch, vcs-diff6800257181085963461.patch The plugin Mojos currently don't have tests. -- 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
[jira] [Commented] (AVRO-1205) Add Stereotype Annotation to Generated Beans
[
https://issues.apache.org/jira/browse/AVRO-1205?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13500022#comment-13500022
]
Sharmarke Aden commented on AVRO-1205:
--
Here is a patch that adds an annotation called AvroSchema and annotates
generated beans with it.
Add Stereotype Annotation to Generated Beans
Key: AVRO-1205
URL: https://issues.apache.org/jira/browse/AVRO-1205
Project: Avro
Issue Type: New Feature
Components: java
Affects Versions: 1.7.2
Reporter: Sharmarke Aden
Priority: Minor
Attachments: vcs-diff6870599675664484518.patch
Avro generated schema beans currently lack a formal way of distinguishing
them as Avro schema beans at runtime. I would like to propose that a new
stereotype annotation be added to Avro Core and the ability to have all Avro
generated schema beans annotated with this newly created stereotype
annotation.
I'm planning on adding a FallbackTypeConverter to the Camel-Avro project and
I hoping this feature will allow me to cleanly detect Avro beans for
conversion at runtime.
If this feature is implemented Avro schema beans would look something like
this:
{code}
...
@org.apache.avro.reflect.AvroSchema
public class User extends org.apache.avro.specific.SpecificRecordBase
implements org.apache.avro.specific.SpecificRecord {
...
}
...
{code}
The maven plugin configuration would look something like this:
{code}
plugin
groupIdorg.apache.avro/groupId
artifactIdavro-maven-plugin/artifactId
executions
execution
goals
goalschema/goal
/goals
/execution
/executions
configuration
stereotypetrue/stereotype
/configuration
/plugin
{code}
--
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
[jira] [Updated] (AVRO-1205) Add Stereotype Annotation to Generated Beans
[
https://issues.apache.org/jira/browse/AVRO-1205?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sharmarke Aden updated AVRO-1205:
-
Attachment: vcs-diff6870599675664484518.patch
Add Stereotype Annotation to Generated Beans
Key: AVRO-1205
URL: https://issues.apache.org/jira/browse/AVRO-1205
Project: Avro
Issue Type: New Feature
Components: java
Affects Versions: 1.7.2
Reporter: Sharmarke Aden
Priority: Minor
Attachments: vcs-diff6870599675664484518.patch
Avro generated schema beans currently lack a formal way of distinguishing
them as Avro schema beans at runtime. I would like to propose that a new
stereotype annotation be added to Avro Core and the ability to have all Avro
generated schema beans annotated with this newly created stereotype
annotation.
I'm planning on adding a FallbackTypeConverter to the Camel-Avro project and
I hoping this feature will allow me to cleanly detect Avro beans for
conversion at runtime.
If this feature is implemented Avro schema beans would look something like
this:
{code}
...
@org.apache.avro.reflect.AvroSchema
public class User extends org.apache.avro.specific.SpecificRecordBase
implements org.apache.avro.specific.SpecificRecord {
...
}
...
{code}
The maven plugin configuration would look something like this:
{code}
plugin
groupIdorg.apache.avro/groupId
artifactIdavro-maven-plugin/artifactId
executions
execution
goals
goalschema/goal
/goals
/execution
/executions
configuration
stereotypetrue/stereotype
/configuration
/plugin
{code}
--
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
[jira] [Commented] (AVRO-1207) Add Mojo Tests to the Maven Pluing
[ https://issues.apache.org/jira/browse/AVRO-1207?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13498862#comment-13498862 ] Sharmarke Aden commented on AVRO-1207: -- This path adds mojo tests to the maven plugin. Add Mojo Tests to the Maven Pluing -- Key: AVRO-1207 URL: https://issues.apache.org/jira/browse/AVRO-1207 Project: Avro Issue Type: Improvement Components: java Affects Versions: 1.7.3 Reporter: Sharmarke Aden Priority: Minor Attachments: vcs-diff6800257181085963461.patch The plugin Mojos currently don't have tests. -- 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
[jira] [Created] (AVRO-1207) Add Mojo Tests to the Maven Pluing
Sharmarke Aden created AVRO-1207: Summary: Add Mojo Tests to the Maven Pluing Key: AVRO-1207 URL: https://issues.apache.org/jira/browse/AVRO-1207 Project: Avro Issue Type: Improvement Components: java Affects Versions: 1.7.3 Reporter: Sharmarke Aden Priority: Minor Attachments: vcs-diff6800257181085963461.patch The plugin Mojos currently don't have tests. -- 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
[jira] [Updated] (AVRO-1207) Add Mojo Tests to the Maven Pluing
[ https://issues.apache.org/jira/browse/AVRO-1207?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sharmarke Aden updated AVRO-1207: - Attachment: vcs-diff6800257181085963461.patch Add Mojo Tests to the Maven Pluing -- Key: AVRO-1207 URL: https://issues.apache.org/jira/browse/AVRO-1207 Project: Avro Issue Type: Improvement Components: java Affects Versions: 1.7.3 Reporter: Sharmarke Aden Priority: Minor Attachments: vcs-diff6800257181085963461.patch The plugin Mojos currently don't have tests. -- 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
[jira] [Commented] (AVRO-1188) External Schema Imports via AVSC Schema
[
https://issues.apache.org/jira/browse/AVRO-1188?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13498867#comment-13498867
]
Sharmarke Aden commented on AVRO-1188:
--
I have created AVRO-1207 and submitted a patch for it. It adds tests for all
the mojos and it also tests schema imports.
External Schema Imports via AVSC Schema
---
Key: AVRO-1188
URL: https://issues.apache.org/jira/browse/AVRO-1188
Project: Avro
Issue Type: New Feature
Components: java
Reporter: Sharmarke Aden
Assignee: Sharmarke Aden
Fix For: 1.7.3
Attachments: Avro-1188.tar.gz, Avro-1188.tar.gz,
vcs-diff1160361655737792386.patch, vcs-diff2916139350460140957.patch,
vcs-diff4277815358664835838.patch, vcs-diff6739872835137179667.patch
There is no way for .avsc schema files to import types (i.e records, enums,
etc) in external schema files. There's tremendous benefit in being able to do
this as it would allow the sharing of common types between multiple schema
files. Here's a use case that illustrates the typical usecase of this feature
request.
Suppose we have an enum called Privacy that we would like to share between
multiple schemas:
{code}
//privacy.avsc
{
type: enum,
name: Privacy,
symbols : [Public, Private]
}
{code}
Now, if this feature was implemented one could import the above type into
other schema files by doing something like this:
{code}
//the post.avsc
{
type: record,
name: Post,
imports: [privacy.avsc] //you can import one or more schemas
fields: [{
name: privacy,
type: [ null, Privacy], //use imported Privacy type
default: Private
}
]
}
{code}
Here's another schema file that also has a similar privacy concern:
{code}
//the event.avsc is another schema that also imports the privacy type
{
type: record,
name: Event,
imports: [privacy.avsc] //it also imports the privacy schemas
fields: [{
name: privacy,
type: [ null, Privacy], //use imported Privacy type
default: Public
}
]
}
{code}
IDL files are able to import external schemas and protocols and it would be
very beneficial if schema files could import other schema files.
--
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
[jira] [Updated] (AVRO-1207) Add Mojo Tests to the Maven Pluing
[ https://issues.apache.org/jira/browse/AVRO-1207?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sharmarke Aden updated AVRO-1207: - Affects Version/s: (was: 1.7.3) 1.7.2 Add Mojo Tests to the Maven Pluing -- Key: AVRO-1207 URL: https://issues.apache.org/jira/browse/AVRO-1207 Project: Avro Issue Type: Improvement Components: java Affects Versions: 1.7.2 Reporter: Sharmarke Aden Priority: Minor Attachments: vcs-diff6800257181085963461.patch The plugin Mojos currently don't have tests. -- 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
[jira] [Updated] (AVRO-1207) Add Mojo Tests to the Maven Plugin
[ https://issues.apache.org/jira/browse/AVRO-1207?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sharmarke Aden updated AVRO-1207: - Summary: Add Mojo Tests to the Maven Plugin (was: Add Mojo Tests to the Maven Pluing) Add Mojo Tests to the Maven Plugin -- Key: AVRO-1207 URL: https://issues.apache.org/jira/browse/AVRO-1207 Project: Avro Issue Type: Improvement Components: java Affects Versions: 1.7.2 Reporter: Sharmarke Aden Assignee: Sharmarke Aden Priority: Minor Fix For: 1.7.3 Attachments: vcs-diff6800257181085963461.patch The plugin Mojos currently don't have tests. -- 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
[jira] [Commented] (AVRO-1188) External Schema Imports via AVSC Schema
[
https://issues.apache.org/jira/browse/AVRO-1188?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13498250#comment-13498250
]
Sharmarke Aden commented on AVRO-1188:
--
Yes, I will take a look at it.
On a side note, is there any reason why there aren't any tests for the plugin
Mojos?
External Schema Imports via AVSC Schema
---
Key: AVRO-1188
URL: https://issues.apache.org/jira/browse/AVRO-1188
Project: Avro
Issue Type: New Feature
Components: java
Reporter: Sharmarke Aden
Assignee: Sharmarke Aden
Fix For: 1.7.3
Attachments: Avro-1188.tar.gz, Avro-1188.tar.gz,
vcs-diff1160361655737792386.patch, vcs-diff2916139350460140957.patch,
vcs-diff4277815358664835838.patch, vcs-diff6739872835137179667.patch
There is no way for .avsc schema files to import types (i.e records, enums,
etc) in external schema files. There's tremendous benefit in being able to do
this as it would allow the sharing of common types between multiple schema
files. Here's a use case that illustrates the typical usecase of this feature
request.
Suppose we have an enum called Privacy that we would like to share between
multiple schemas:
{code}
//privacy.avsc
{
type: enum,
name: Privacy,
symbols : [Public, Private]
}
{code}
Now, if this feature was implemented one could import the above type into
other schema files by doing something like this:
{code}
//the post.avsc
{
type: record,
name: Post,
imports: [privacy.avsc] //you can import one or more schemas
fields: [{
name: privacy,
type: [ null, Privacy], //use imported Privacy type
default: Private
}
]
}
{code}
Here's another schema file that also has a similar privacy concern:
{code}
//the event.avsc is another schema that also imports the privacy type
{
type: record,
name: Event,
imports: [privacy.avsc] //it also imports the privacy schemas
fields: [{
name: privacy,
type: [ null, Privacy], //use imported Privacy type
default: Public
}
]
}
{code}
IDL files are able to import external schemas and protocols and it would be
very beneficial if schema files could import other schema files.
--
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
[jira] [Created] (AVRO-1205) Add Stereotype Annotation to Generated Beans
Sharmarke Aden created AVRO-1205:
Summary: Add Stereotype Annotation to Generated Beans
Key: AVRO-1205
URL: https://issues.apache.org/jira/browse/AVRO-1205
Project: Avro
Issue Type: New Feature
Components: java
Affects Versions: 1.7.2
Reporter: Sharmarke Aden
Priority: Minor
Avro generated schema beans currently lack a formal way of distinguishing them
as Avro schema beans at runtime. I would like to propose that a new stereotype
annotation be added to Avro Core and the ability to have all Avro generated
schema beans annotated with this newly created stereotype annotation.
I'm planning on adding a FallbackTypeConverter to the Camel-Avro project and I
hoping this feature will allow me to cleanly detect Avro beans for conversion
at runtime.
If this feature is implemented Avro schema beans would look something like this:
{code}
...
@org.apache.avro.reflect.AvroSchema
public class User extends org.apache.avro.specific.SpecificRecordBase
implements org.apache.avro.specific.SpecificRecord {
...
}
...
{code}
The maven plugin configuration would look something like this:
{code}
plugin
groupIdorg.apache.avro/groupId
artifactIdavro-maven-plugin/artifactId
executions
execution
goals
goalschema/goal
/goals
/execution
/executions
configuration
stereotypetrue/stereotype
/configuration
/plugin
{code}
--
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
[jira] [Commented] (AVRO-1188) External Schema Imports via AVSC Schema
[
https://issues.apache.org/jira/browse/AVRO-1188?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13497481#comment-13497481
]
Sharmarke Aden commented on AVRO-1188:
--
I would very much like to add unit tests but I'm not sure where they should be
added.
External Schema Imports via AVSC Schema
---
Key: AVRO-1188
URL: https://issues.apache.org/jira/browse/AVRO-1188
Project: Avro
Issue Type: New Feature
Components: java
Reporter: Sharmarke Aden
Assignee: Sharmarke Aden
Fix For: 1.7.3
Attachments: Avro-1188.tar.gz, Avro-1188.tar.gz,
vcs-diff1160361655737792386.patch, vcs-diff2916139350460140957.patch,
vcs-diff4277815358664835838.patch, vcs-diff6739872835137179667.patch
There is no way for .avsc schema files to import types (i.e records, enums,
etc) in external schema files. There's tremendous benefit in being able to do
this as it would allow the sharing of common types between multiple schema
files. Here's a use case that illustrates the typical usecase of this feature
request.
Suppose we have an enum called Privacy that we would like to share between
multiple schemas:
{code}
//privacy.avsc
{
type: enum,
name: Privacy,
symbols : [Public, Private]
}
{code}
Now, if this feature was implemented one could import the above type into
other schema files by doing something like this:
{code}
//the post.avsc
{
type: record,
name: Post,
imports: [privacy.avsc] //you can import one or more schemas
fields: [{
name: privacy,
type: [ null, Privacy], //use imported Privacy type
default: Private
}
]
}
{code}
Here's another schema file that also has a similar privacy concern:
{code}
//the event.avsc is another schema that also imports the privacy type
{
type: record,
name: Event,
imports: [privacy.avsc] //it also imports the privacy schemas
fields: [{
name: privacy,
type: [ null, Privacy], //use imported Privacy type
default: Public
}
]
}
{code}
IDL files are able to import external schemas and protocols and it would be
very beneficial if schema files could import other schema files.
--
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
[jira] [Commented] (AVRO-1205) Add Stereotype Annotation to Generated Beans
[
https://issues.apache.org/jira/browse/AVRO-1205?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13497682#comment-13497682
]
Sharmarke Aden commented on AVRO-1205:
--
There is no harm in always adding an annotation to emitted classes and doing so
would preferable. I don't know enough about package placement preference in
Avro so I will deffer to you on the matter.
With respect to using Generated annotation, I believe annotating all generated
beans using standard annotations would be wise but as you've mentioned it makes
runtime detection of Avro beans a bit more cumbersome and clunky. My preference
is to have Avro own its annotation(s) much like JAXB and various other
frameworks.
Add Stereotype Annotation to Generated Beans
Key: AVRO-1205
URL: https://issues.apache.org/jira/browse/AVRO-1205
Project: Avro
Issue Type: New Feature
Components: java
Affects Versions: 1.7.2
Reporter: Sharmarke Aden
Priority: Minor
Avro generated schema beans currently lack a formal way of distinguishing
them as Avro schema beans at runtime. I would like to propose that a new
stereotype annotation be added to Avro Core and the ability to have all Avro
generated schema beans annotated with this newly created stereotype
annotation.
I'm planning on adding a FallbackTypeConverter to the Camel-Avro project and
I hoping this feature will allow me to cleanly detect Avro beans for
conversion at runtime.
If this feature is implemented Avro schema beans would look something like
this:
{code}
...
@org.apache.avro.reflect.AvroSchema
public class User extends org.apache.avro.specific.SpecificRecordBase
implements org.apache.avro.specific.SpecificRecord {
...
}
...
{code}
The maven plugin configuration would look something like this:
{code}
plugin
groupIdorg.apache.avro/groupId
artifactIdavro-maven-plugin/artifactId
executions
execution
goals
goalschema/goal
/goals
/execution
/executions
configuration
stereotypetrue/stereotype
/configuration
/plugin
{code}
--
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
[jira] [Commented] (AVRO-1188) External Schema Imports via AVSC Schema
[
https://issues.apache.org/jira/browse/AVRO-1188?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13496465#comment-13496465
]
Sharmarke Aden commented on AVRO-1188:
--
My pleasure. Thanks you guys for your guidance.
External Schema Imports via AVSC Schema
---
Key: AVRO-1188
URL: https://issues.apache.org/jira/browse/AVRO-1188
Project: Avro
Issue Type: New Feature
Components: java
Reporter: Sharmarke Aden
Assignee: Sharmarke Aden
Fix For: 1.7.3
Attachments: Avro-1188.tar.gz, Avro-1188.tar.gz,
vcs-diff1160361655737792386.patch, vcs-diff2916139350460140957.patch,
vcs-diff4277815358664835838.patch, vcs-diff6739872835137179667.patch
There is no way for .avsc schema files to import types (i.e records, enums,
etc) in external schema files. There's tremendous benefit in being able to do
this as it would allow the sharing of common types between multiple schema
files. Here's a use case that illustrates the typical usecase of this feature
request.
Suppose we have an enum called Privacy that we would like to share between
multiple schemas:
{code}
//privacy.avsc
{
type: enum,
name: Privacy,
symbols : [Public, Private]
}
{code}
Now, if this feature was implemented one could import the above type into
other schema files by doing something like this:
{code}
//the post.avsc
{
type: record,
name: Post,
imports: [privacy.avsc] //you can import one or more schemas
fields: [{
name: privacy,
type: [ null, Privacy], //use imported Privacy type
default: Private
}
]
}
{code}
Here's another schema file that also has a similar privacy concern:
{code}
//the event.avsc is another schema that also imports the privacy type
{
type: record,
name: Event,
imports: [privacy.avsc] //it also imports the privacy schemas
fields: [{
name: privacy,
type: [ null, Privacy], //use imported Privacy type
default: Public
}
]
}
{code}
IDL files are able to import external schemas and protocols and it would be
very beneficial if schema files could import other schema files.
--
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
[jira] [Updated] (AVRO-1188) External Schema Imports via AVSC Schema
[
https://issues.apache.org/jira/browse/AVRO-1188?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sharmarke Aden updated AVRO-1188:
-
Attachment: vcs-diff1160361655737792386.patch
External Schema Imports via AVSC Schema
---
Key: AVRO-1188
URL: https://issues.apache.org/jira/browse/AVRO-1188
Project: Avro
Issue Type: New Feature
Components: java
Reporter: Sharmarke Aden
Attachments: Avro-1188.tar.gz, vcs-diff1160361655737792386.patch,
vcs-diff2916139350460140957.patch, vcs-diff4277815358664835838.patch
There is no way for .avsc schema files to import types (i.e records, enums,
etc) in external schema files. There's tremendous benefit in being able to do
this as it would allow the sharing of common types between multiple schema
files. Here's a use case that illustrates the typical usecase of this feature
request.
Suppose we have an enum called Privacy that we would like to share between
multiple schemas:
{code}
//privacy.avsc
{
type: enum,
name: Privacy,
symbols : [Public, Private]
}
{code}
Now, if this feature was implemented one could import the above type into
other schema files by doing something like this:
{code}
//the post.avsc
{
type: record,
name: Post,
imports: [privacy.avsc] //you can import one or more schemas
fields: [{
name: privacy,
type: [ null, Privacy], //use imported Privacy type
default: Private
}
]
}
{code}
Here's another schema file that also has a similar privacy concern:
{code}
//the event.avsc is another schema that also imports the privacy type
{
type: record,
name: Event,
imports: [privacy.avsc] //it also imports the privacy schemas
fields: [{
name: privacy,
type: [ null, Privacy], //use imported Privacy type
default: Public
}
]
}
{code}
IDL files are able to import external schemas and protocols and it would be
very beneficial if schema files could import other schema files.
--
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
[jira] [Commented] (AVRO-1188) External Schema Imports via AVSC Schema
[
https://issues.apache.org/jira/browse/AVRO-1188?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13495235#comment-13495235
]
Sharmarke Aden commented on AVRO-1188:
--
This patch makes everything hunky-dory and backward compatible by checking to
see if the user opted in to the importing of files. If user specified
importedFiles then a single schema parser is used otherwise we do things the
old way and create a new schema parser every time.
External Schema Imports via AVSC Schema
---
Key: AVRO-1188
URL: https://issues.apache.org/jira/browse/AVRO-1188
Project: Avro
Issue Type: New Feature
Components: java
Reporter: Sharmarke Aden
Attachments: Avro-1188.tar.gz, vcs-diff1160361655737792386.patch,
vcs-diff2916139350460140957.patch, vcs-diff4277815358664835838.patch
There is no way for .avsc schema files to import types (i.e records, enums,
etc) in external schema files. There's tremendous benefit in being able to do
this as it would allow the sharing of common types between multiple schema
files. Here's a use case that illustrates the typical usecase of this feature
request.
Suppose we have an enum called Privacy that we would like to share between
multiple schemas:
{code}
//privacy.avsc
{
type: enum,
name: Privacy,
symbols : [Public, Private]
}
{code}
Now, if this feature was implemented one could import the above type into
other schema files by doing something like this:
{code}
//the post.avsc
{
type: record,
name: Post,
imports: [privacy.avsc] //you can import one or more schemas
fields: [{
name: privacy,
type: [ null, Privacy], //use imported Privacy type
default: Private
}
]
}
{code}
Here's another schema file that also has a similar privacy concern:
{code}
//the event.avsc is another schema that also imports the privacy type
{
type: record,
name: Event,
imports: [privacy.avsc] //it also imports the privacy schemas
fields: [{
name: privacy,
type: [ null, Privacy], //use imported Privacy type
default: Public
}
]
}
{code}
IDL files are able to import external schemas and protocols and it would be
very beneficial if schema files could import other schema files.
--
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
[jira] [Commented] (AVRO-1188) External Schema Imports via AVSC Schema
[
https://issues.apache.org/jira/browse/AVRO-1188?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13495378#comment-13495378
]
Sharmarke Aden commented on AVRO-1188:
--
Updated the patch based on Tom's valuable feedback. Please note that I also
changed the plugin coUpdated the patch based on Tom's feedback. Please note
that I also changed the plugin importedFiles configuration to just imports
External Schema Imports via AVSC Schema
---
Key: AVRO-1188
URL: https://issues.apache.org/jira/browse/AVRO-1188
Project: Avro
Issue Type: New Feature
Components: java
Reporter: Sharmarke Aden
Assignee: Sharmarke Aden
Attachments: Avro-1188.tar.gz, vcs-diff1160361655737792386.patch,
vcs-diff2916139350460140957.patch, vcs-diff4277815358664835838.patch,
vcs-diff6739872835137179667.patch
There is no way for .avsc schema files to import types (i.e records, enums,
etc) in external schema files. There's tremendous benefit in being able to do
this as it would allow the sharing of common types between multiple schema
files. Here's a use case that illustrates the typical usecase of this feature
request.
Suppose we have an enum called Privacy that we would like to share between
multiple schemas:
{code}
//privacy.avsc
{
type: enum,
name: Privacy,
symbols : [Public, Private]
}
{code}
Now, if this feature was implemented one could import the above type into
other schema files by doing something like this:
{code}
//the post.avsc
{
type: record,
name: Post,
imports: [privacy.avsc] //you can import one or more schemas
fields: [{
name: privacy,
type: [ null, Privacy], //use imported Privacy type
default: Private
}
]
}
{code}
Here's another schema file that also has a similar privacy concern:
{code}
//the event.avsc is another schema that also imports the privacy type
{
type: record,
name: Event,
imports: [privacy.avsc] //it also imports the privacy schemas
fields: [{
name: privacy,
type: [ null, Privacy], //use imported Privacy type
default: Public
}
]
}
{code}
IDL files are able to import external schemas and protocols and it would be
very beneficial if schema files could import other schema files.
--
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
[jira] [Updated] (AVRO-1188) External Schema Imports via AVSC Schema
[
https://issues.apache.org/jira/browse/AVRO-1188?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sharmarke Aden updated AVRO-1188:
-
Attachment: vcs-diff6739872835137179667.patch
External Schema Imports via AVSC Schema
---
Key: AVRO-1188
URL: https://issues.apache.org/jira/browse/AVRO-1188
Project: Avro
Issue Type: New Feature
Components: java
Reporter: Sharmarke Aden
Assignee: Sharmarke Aden
Attachments: Avro-1188.tar.gz, vcs-diff1160361655737792386.patch,
vcs-diff2916139350460140957.patch, vcs-diff4277815358664835838.patch,
vcs-diff6739872835137179667.patch
There is no way for .avsc schema files to import types (i.e records, enums,
etc) in external schema files. There's tremendous benefit in being able to do
this as it would allow the sharing of common types between multiple schema
files. Here's a use case that illustrates the typical usecase of this feature
request.
Suppose we have an enum called Privacy that we would like to share between
multiple schemas:
{code}
//privacy.avsc
{
type: enum,
name: Privacy,
symbols : [Public, Private]
}
{code}
Now, if this feature was implemented one could import the above type into
other schema files by doing something like this:
{code}
//the post.avsc
{
type: record,
name: Post,
imports: [privacy.avsc] //you can import one or more schemas
fields: [{
name: privacy,
type: [ null, Privacy], //use imported Privacy type
default: Private
}
]
}
{code}
Here's another schema file that also has a similar privacy concern:
{code}
//the event.avsc is another schema that also imports the privacy type
{
type: record,
name: Event,
imports: [privacy.avsc] //it also imports the privacy schemas
fields: [{
name: privacy,
type: [ null, Privacy], //use imported Privacy type
default: Public
}
]
}
{code}
IDL files are able to import external schemas and protocols and it would be
very beneficial if schema files could import other schema files.
--
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
[jira] [Updated] (AVRO-1188) External Schema Imports via AVSC Schema
[
https://issues.apache.org/jira/browse/AVRO-1188?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sharmarke Aden updated AVRO-1188:
-
Attachment: vcs-diff4277815358664835838.patch
External Schema Imports via AVSC Schema
---
Key: AVRO-1188
URL: https://issues.apache.org/jira/browse/AVRO-1188
Project: Avro
Issue Type: New Feature
Components: java
Reporter: Sharmarke Aden
Attachments: vcs-diff4277815358664835838.patch
There is no way for .avsc schema files to import types (i.e records, enums,
etc) in external schema files. There's tremendous benefit in being able to do
this as it would allow the sharing of common types between multiple schema
files. Here's a use case that illustrates the typical usecase of this feature
request.
Suppose we have an enum called Privacy that we would like to share between
multiple schemas:
{code}
//privacy.avsc
{
type: enum,
name: Privacy,
symbols : [Public, Private]
}
{code}
Now, if this feature was implemented one could import the above type into
other schema files by doing something like this:
{code}
//the post.avsc
{
type: record,
name: Post,
imports: [privacy.avsc] //you can import one or more schemas
fields: [{
name: privacy,
type: [ null, Privacy], //use imported Privacy type
default: Private
}
]
}
{code}
Here's another schema file that also has a similar privacy concern:
{code}
//the event.avsc is another schema that also imports the privacy type
{
type: record,
name: Event,
imports: [privacy.avsc] //it also imports the privacy schemas
fields: [{
name: privacy,
type: [ null, Privacy], //use imported Privacy type
default: Public
}
]
}
{code}
IDL files are able to import external schemas and protocols and it would be
very beneficial if schema files could import other schema files.
--
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
[jira] [Commented] (AVRO-1188) External Schema Imports via AVSC Schema
[
https://issues.apache.org/jira/browse/AVRO-1188?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13494954#comment-13494954
]
Sharmarke Aden commented on AVRO-1188:
--
This patch adds the ability to import directories or files to the maven plugin
External Schema Imports via AVSC Schema
---
Key: AVRO-1188
URL: https://issues.apache.org/jira/browse/AVRO-1188
Project: Avro
Issue Type: New Feature
Components: java
Reporter: Sharmarke Aden
Attachments: vcs-diff4277815358664835838.patch
There is no way for .avsc schema files to import types (i.e records, enums,
etc) in external schema files. There's tremendous benefit in being able to do
this as it would allow the sharing of common types between multiple schema
files. Here's a use case that illustrates the typical usecase of this feature
request.
Suppose we have an enum called Privacy that we would like to share between
multiple schemas:
{code}
//privacy.avsc
{
type: enum,
name: Privacy,
symbols : [Public, Private]
}
{code}
Now, if this feature was implemented one could import the above type into
other schema files by doing something like this:
{code}
//the post.avsc
{
type: record,
name: Post,
imports: [privacy.avsc] //you can import one or more schemas
fields: [{
name: privacy,
type: [ null, Privacy], //use imported Privacy type
default: Private
}
]
}
{code}
Here's another schema file that also has a similar privacy concern:
{code}
//the event.avsc is another schema that also imports the privacy type
{
type: record,
name: Event,
imports: [privacy.avsc] //it also imports the privacy schemas
fields: [{
name: privacy,
type: [ null, Privacy], //use imported Privacy type
default: Public
}
]
}
{code}
IDL files are able to import external schemas and protocols and it would be
very beneficial if schema files could import other schema files.
--
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
[jira] [Updated] (AVRO-1188) External Schema Imports via AVSC Schema
[
https://issues.apache.org/jira/browse/AVRO-1188?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sharmarke Aden updated AVRO-1188:
-
Attachment: Avro-1188.tar.gz
Here is a simple project that demonstrates the import feature.
External Schema Imports via AVSC Schema
---
Key: AVRO-1188
URL: https://issues.apache.org/jira/browse/AVRO-1188
Project: Avro
Issue Type: New Feature
Components: java
Reporter: Sharmarke Aden
Attachments: Avro-1188.tar.gz, vcs-diff4277815358664835838.patch
There is no way for .avsc schema files to import types (i.e records, enums,
etc) in external schema files. There's tremendous benefit in being able to do
this as it would allow the sharing of common types between multiple schema
files. Here's a use case that illustrates the typical usecase of this feature
request.
Suppose we have an enum called Privacy that we would like to share between
multiple schemas:
{code}
//privacy.avsc
{
type: enum,
name: Privacy,
symbols : [Public, Private]
}
{code}
Now, if this feature was implemented one could import the above type into
other schema files by doing something like this:
{code}
//the post.avsc
{
type: record,
name: Post,
imports: [privacy.avsc] //you can import one or more schemas
fields: [{
name: privacy,
type: [ null, Privacy], //use imported Privacy type
default: Private
}
]
}
{code}
Here's another schema file that also has a similar privacy concern:
{code}
//the event.avsc is another schema that also imports the privacy type
{
type: record,
name: Event,
imports: [privacy.avsc] //it also imports the privacy schemas
fields: [{
name: privacy,
type: [ null, Privacy], //use imported Privacy type
default: Public
}
]
}
{code}
IDL files are able to import external schemas and protocols and it would be
very beneficial if schema files could import other schema files.
--
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
[jira] [Updated] (AVRO-1188) External Schema Imports via AVSC Schema
[
https://issues.apache.org/jira/browse/AVRO-1188?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sharmarke Aden updated AVRO-1188:
-
Attachment: vcs-diff2916139350460140957.patch
External Schema Imports via AVSC Schema
---
Key: AVRO-1188
URL: https://issues.apache.org/jira/browse/AVRO-1188
Project: Avro
Issue Type: New Feature
Components: java
Reporter: Sharmarke Aden
Attachments: Avro-1188.tar.gz, vcs-diff2916139350460140957.patch,
vcs-diff4277815358664835838.patch
There is no way for .avsc schema files to import types (i.e records, enums,
etc) in external schema files. There's tremendous benefit in being able to do
this as it would allow the sharing of common types between multiple schema
files. Here's a use case that illustrates the typical usecase of this feature
request.
Suppose we have an enum called Privacy that we would like to share between
multiple schemas:
{code}
//privacy.avsc
{
type: enum,
name: Privacy,
symbols : [Public, Private]
}
{code}
Now, if this feature was implemented one could import the above type into
other schema files by doing something like this:
{code}
//the post.avsc
{
type: record,
name: Post,
imports: [privacy.avsc] //you can import one or more schemas
fields: [{
name: privacy,
type: [ null, Privacy], //use imported Privacy type
default: Private
}
]
}
{code}
Here's another schema file that also has a similar privacy concern:
{code}
//the event.avsc is another schema that also imports the privacy type
{
type: record,
name: Event,
imports: [privacy.avsc] //it also imports the privacy schemas
fields: [{
name: privacy,
type: [ null, Privacy], //use imported Privacy type
default: Public
}
]
}
{code}
IDL files are able to import external schemas and protocols and it would be
very beneficial if schema files could import other schema files.
--
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
[jira] [Commented] (AVRO-1188) External Schema Imports via AVSC Schema
[
https://issues.apache.org/jira/browse/AVRO-1188?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13495019#comment-13495019
]
Sharmarke Aden commented on AVRO-1188:
--
This patch also displays the same symptoms as AVRO-983 patch. Having a single
Schema.Parser causes the IPC module to fail with Can't redefine:
org.apache.avro.ipc.MD5
External Schema Imports via AVSC Schema
---
Key: AVRO-1188
URL: https://issues.apache.org/jira/browse/AVRO-1188
Project: Avro
Issue Type: New Feature
Components: java
Reporter: Sharmarke Aden
Attachments: Avro-1188.tar.gz, vcs-diff2916139350460140957.patch,
vcs-diff4277815358664835838.patch
There is no way for .avsc schema files to import types (i.e records, enums,
etc) in external schema files. There's tremendous benefit in being able to do
this as it would allow the sharing of common types between multiple schema
files. Here's a use case that illustrates the typical usecase of this feature
request.
Suppose we have an enum called Privacy that we would like to share between
multiple schemas:
{code}
//privacy.avsc
{
type: enum,
name: Privacy,
symbols : [Public, Private]
}
{code}
Now, if this feature was implemented one could import the above type into
other schema files by doing something like this:
{code}
//the post.avsc
{
type: record,
name: Post,
imports: [privacy.avsc] //you can import one or more schemas
fields: [{
name: privacy,
type: [ null, Privacy], //use imported Privacy type
default: Private
}
]
}
{code}
Here's another schema file that also has a similar privacy concern:
{code}
//the event.avsc is another schema that also imports the privacy type
{
type: record,
name: Event,
imports: [privacy.avsc] //it also imports the privacy schemas
fields: [{
name: privacy,
type: [ null, Privacy], //use imported Privacy type
default: Public
}
]
}
{code}
IDL files are able to import external schemas and protocols and it would be
very beneficial if schema files could import other schema files.
--
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
[jira] [Updated] (AVRO-1201) CLONE - GenericRecord.toString can produce invalid JSON
[
https://issues.apache.org/jira/browse/AVRO-1201?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sharmarke Aden updated AVRO-1201:
-
Attachment: avro-1201.patch
Here's an updated patch that contains changes suggested by Doug.
CLONE - GenericRecord.toString can produce invalid JSON
---
Key: AVRO-1201
URL: https://issues.apache.org/jira/browse/AVRO-1201
Project: Avro
Issue Type: Bug
Components: java
Affects Versions: 1.7.2
Reporter: Sharmarke Aden
Assignee: Jay Kreps
Attachments: avro-1201.patch, avro-1201.patch,
Avro-1201-TestCase.tar.gz
The GenericData.toString method can produce invalid JSON. The problem is that
enums are printed without quotes, as in
{emum_field:a}
instead of
{enum_field:a}
--
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
[jira] [Created] (AVRO-1201) CLONE - GenericRecord.toString can produce invalid JSON
Sharmarke Aden created AVRO-1201:
Summary: CLONE - GenericRecord.toString can produce invalid JSON
Key: AVRO-1201
URL: https://issues.apache.org/jira/browse/AVRO-1201
Project: Avro
Issue Type: Bug
Components: java
Affects Versions: 1.4.1
Reporter: Sharmarke Aden
Assignee: Jay Kreps
Fix For: 1.5.0
The GenericData.toString method can produce invalid JSON. The problem is that
enums are printed without quotes, as in
{emum_field:a}
instead of
{enum_field:a}
--
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
[jira] [Commented] (AVRO-1201) CLONE - GenericRecord.toString can produce invalid JSON
[
https://issues.apache.org/jira/browse/AVRO-1201?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13494073#comment-13494073
]
Sharmarke Aden commented on AVRO-1201:
--
GenericData toString() method doesn't check to see if datum instanceof Enum
and appropriately handle enums. This results in an invalid json being produced
similar to the one seen in AVRO-713.
CLONE - GenericRecord.toString can produce invalid JSON
---
Key: AVRO-1201
URL: https://issues.apache.org/jira/browse/AVRO-1201
Project: Avro
Issue Type: Bug
Components: java
Affects Versions: 1.4.1
Reporter: Sharmarke Aden
Assignee: Jay Kreps
Fix For: 1.5.0
The GenericData.toString method can produce invalid JSON. The problem is that
enums are printed without quotes, as in
{emum_field:a}
instead of
{enum_field:a}
--
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
[jira] [Updated] (AVRO-1201) CLONE - GenericRecord.toString can produce invalid JSON
[
https://issues.apache.org/jira/browse/AVRO-1201?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sharmarke Aden updated AVRO-1201:
-
Fix Version/s: (was: 1.5.0)
CLONE - GenericRecord.toString can produce invalid JSON
---
Key: AVRO-1201
URL: https://issues.apache.org/jira/browse/AVRO-1201
Project: Avro
Issue Type: Bug
Components: java
Affects Versions: 1.7.2
Reporter: Sharmarke Aden
Assignee: Jay Kreps
Attachments: Avro-1201-TestCase.tar.gz
The GenericData.toString method can produce invalid JSON. The problem is that
enums are printed without quotes, as in
{emum_field:a}
instead of
{enum_field:a}
--
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
[jira] [Updated] (AVRO-1201) CLONE - GenericRecord.toString can produce invalid JSON
[
https://issues.apache.org/jira/browse/AVRO-1201?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sharmarke Aden updated AVRO-1201:
-
Affects Version/s: (was: 1.4.1)
1.7.2
CLONE - GenericRecord.toString can produce invalid JSON
---
Key: AVRO-1201
URL: https://issues.apache.org/jira/browse/AVRO-1201
Project: Avro
Issue Type: Bug
Components: java
Affects Versions: 1.7.2
Reporter: Sharmarke Aden
Assignee: Jay Kreps
Attachments: Avro-1201-TestCase.tar.gz
The GenericData.toString method can produce invalid JSON. The problem is that
enums are printed without quotes, as in
{emum_field:a}
instead of
{enum_field:a}
--
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
[jira] [Updated] (AVRO-1201) CLONE - GenericRecord.toString can produce invalid JSON
[
https://issues.apache.org/jira/browse/AVRO-1201?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sharmarke Aden updated AVRO-1201:
-
Attachment: Avro-1201-TestCase.tar.gz
Here is a test case that demonstrates the issue.
CLONE - GenericRecord.toString can produce invalid JSON
---
Key: AVRO-1201
URL: https://issues.apache.org/jira/browse/AVRO-1201
Project: Avro
Issue Type: Bug
Components: java
Affects Versions: 1.7.2
Reporter: Sharmarke Aden
Assignee: Jay Kreps
Attachments: Avro-1201-TestCase.tar.gz
The GenericData.toString method can produce invalid JSON. The problem is that
enums are printed without quotes, as in
{emum_field:a}
instead of
{enum_field:a}
--
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
[jira] [Commented] (AVRO-1201) CLONE - GenericRecord.toString can produce invalid JSON
[
https://issues.apache.org/jira/browse/AVRO-1201?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13494349#comment-13494349
]
Sharmarke Aden commented on AVRO-1201:
--
That works even better.
CLONE - GenericRecord.toString can produce invalid JSON
---
Key: AVRO-1201
URL: https://issues.apache.org/jira/browse/AVRO-1201
Project: Avro
Issue Type: Bug
Components: java
Affects Versions: 1.7.2
Reporter: Sharmarke Aden
Assignee: Jay Kreps
Attachments: avro-1201.patch, Avro-1201-TestCase.tar.gz
The GenericData.toString method can produce invalid JSON. The problem is that
enums are printed without quotes, as in
{emum_field:a}
instead of
{enum_field:a}
--
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
[jira] [Updated] (AVRO-1188) External Schema Imports via AVSC Schema
[
https://issues.apache.org/jira/browse/AVRO-1188?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sharmarke Aden updated AVRO-1188:
-
Description:
There is no way for .avsc schema files to import types (i.e records, enums,
etc) in external schema files. There's tremendous benefit in being able to do
this as it would allow the sharing of common types between multiple schema
files. Here's a use case that illustrates the typical usecase of this feature
request.
Suppose we have an enum called Privacy that we would like to share between
multiple schemas:
{code}
//privacy.avsc
{
type: enum,
name: Privacy,
symbols : [Public, Private]
}
{code}
Now, if this feature was implemented one could import the above type into other
schema files by doing something like this:
{code}
//the post.avsc
{
type: record,
name: Post,
imports: [privacy.avsc] //you can import one or more schemas
fields: [{
name: privacy,
type: [ null, Privacy], //use imported Privacy type
default: Private
}
]
}
{code}
Here's another schema file that also has a similar privacy concern:
{code}
//the event.avsc is another schema that also imports the privacy type
{
type: record,
name: Event,
imports: [privacy.avsc] //it also imports the privacy schemas
fields: [{
name: privacy,
type: [ null, Privacy], //use imported Privacy type
default: Public
}
]
}
{code}
IDL files are able to import external schemas and protocols and it would be
very beneficial if schema files could import other schema files.
was:
There is no way for .avsc schema files to import types (i.e records, enums,
etc) in external schema files. There's tremendous benefit in being able to do
this as it would all for the sharing of common types between multiple schema
files. Here's a use case that illustrates the typical usecase of this feature
request.
Suppose we have an enum called Privacy that we would like to share between
multiple schemas:
{code}
//privacy.avsc
{
type: enum,
name: Privacy,
symbols : [Public, Private]
}
{code}
Now, if this feature was implemented one could import the above type into other
schema files by doing something like this:
{code}
//the post.avsc
{
type: record,
name: Post,
imports: [privacy.avsc] //you can import one or more schemas
fields: [{
name: privacy,
type: [ null, Privacy], //use imported Privacy type
default: Private
}
]
}
{code}
Here's another schema file that also has a similar privacy concern:
{code}
//the event.avsc is another schema that also imports the privacy type
{
type: record,
name: Event,
imports: [privacy.avsc] //it also imports the privacy schemas
fields: [{
name: privacy,
type: [ null, Privacy], //use imported Privacy type
default: Public
}
]
}
{code}
IDL files are able to import external schemas and protocols and it would be
very beneficial if schema files could import other schema files.
External Schema Imports via AVSC Schema
---
Key: AVRO-1188
URL: https://issues.apache.org/jira/browse/AVRO-1188
Project: Avro
Issue Type: New Feature
Components: java
Reporter: Sharmarke Aden
There is no way for .avsc schema files to import types (i.e records, enums,
etc) in external schema files. There's tremendous benefit in being able to do
this as it would allow the sharing of common types between multiple schema
files. Here's a use case that illustrates the typical usecase of this feature
request.
Suppose we have an enum called Privacy that we would like to share between
multiple schemas:
{code}
//privacy.avsc
{
type: enum,
name: Privacy,
symbols : [Public, Private]
}
{code}
Now, if this feature was implemented one could import the above type into
other schema files by doing something like this:
{code}
//the post.avsc
{
type: record,
name: Post,
imports: [privacy.avsc] //you can import one or more schemas
fields: [{
name: privacy,
type: [ null, Privacy], //use imported Privacy type
default: Private
}
]
}
{code}
Here's another schema file that also has a similar privacy concern:
{code}
//the event.avsc is another schema that also imports the privacy type
{
type: record,
name: Event,
imports: [privacy.avsc] //it also imports the privacy schemas
fields: [{
name: privacy,
type: [ null, Privacy], //use imported Privacy type
default: Public
}
]
}
{code}
IDL files are able to import external schemas and protocols and it would be
very beneficial if schema files
[jira] [Commented] (AVRO-1188) External Schema Imports via AVSC Schema
[
https://issues.apache.org/jira/browse/AVRO-1188?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13490916#comment-13490916
]
Sharmarke Aden commented on AVRO-1188:
--
Looking at AVRO-983 it seems that this issue is somewhat of a duplicate issue.
I searched for a similar issue but didn't have luck finding it. Yes,
utilization of the order technique will work for us though I wonder if there
should be better way of schema imports based on previously loaded/compiled
schemas without having to rely on the order of files/directorys. What do you
think of the idea of having an explicit imports directory that's passed via
command-line/maven which is processed/compiled before any other schemas?
In maven one would define a configuration property called importsDirectory/
that points to a directory containing schemas that should be processed first.
Perhaps this directory could default to src/main/avro/imports which is
treated as a special reserved directory by the maven plugin. The maven plugin
declaration would look like this:
{code}
plugin
groupIdorg.apache.avro/groupId
artifactIdavro-maven-plugin/artifactId
executions
execution
goals
goalschema/goal
/goals
/execution
/executions
configuration
importsDirectory${basedir}/src/main/avro/imports/importsDirectory
/configuration
/plugin
{code}
I am not familiar with the command-line tool but I would imagine a command-line
option called -imports can be added that allows a user to specify an import
directory that gets processed before other schemas.
{code}
java -jar avro-tools-XXX.jar -imports /schema/import/directory ...
{code}
External Schema Imports via AVSC Schema
---
Key: AVRO-1188
URL: https://issues.apache.org/jira/browse/AVRO-1188
Project: Avro
Issue Type: New Feature
Components: java
Reporter: Sharmarke Aden
There is no way for .avsc schema files to import types (i.e records, enums,
etc) in external schema files. There's tremendous benefit in being able to do
this as it would all for the sharing of common types between multiple schema
files. Here's a use case that illustrates the typical usecase of this feature
request.
Suppose we have an enum called Privacy that we would like to share between
multiple schemas:
{code}
//privacy.avsc
{
type: enum,
name: Privacy,
symbols : [Public, Private]
}
{code}
Now, if this feature was implemented one could import the above type into
other schema files by doing something like this:
{code}
//the post.avsc
{
type: record,
name: Post,
imports: [privacy.avsc] //you can import one or more schemas
fields: [{
name: privacy,
type: [ null, Privacy], //use imported Privacy type
default: Private
}
]
}
{code}
Here's another schema file that also has a similar privacy concern:
{code}
//the event.avsc is another schema that also imports the privacy type
{
type: record,
name: Event,
imports: [privacy.avsc] //it also imports the privacy schemas
fields: [{
name: privacy,
type: [ null, Privacy], //use imported Privacy type
default: Public
}
]
}
{code}
IDL files are able to import external schemas and protocols and it would be
very beneficial if schema files could import other schema files.
--
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
[jira] [Created] (AVRO-1188) External Schema Imports via AVSC Schema
Sharmarke Aden created AVRO-1188:
Summary: External Schema Imports via AVSC Schema
Key: AVRO-1188
URL: https://issues.apache.org/jira/browse/AVRO-1188
Project: Avro
Issue Type: New Feature
Components: java
Reporter: Sharmarke Aden
There is no way for .avsc schema files to import types (i.e records, enums,
etc) in external schema files. There's tremendous benefit in being able to do
this as it would all for the sharing of common types between multiple schema
files. Here's a use case that illustrates the typical usecase of this feature
request.
Suppose we have an enum called Privacy that we would like to share between
multiple schemas:
{code}
//privacy.avsc
{
type: enum,
name: Privacy,
symbols : [Public, Private]
}
{code}
Now, if this feature was implemented one could import the above type into other
schema files by doing something like this:
{code}
//the post.avsc
{
type: record,
name: Post,
imports: [privacy.avsc] //you can import one or more schemas
fields: [{
name: privacy,
type: [ null, Privacy], //use imported Privacy type
default: Private
}
]
}
{code}
Here's another schema file that also has a similar privacy concern:
{code}
//the event.avsc is another schema that also imports the privacy type
{
type: record,
name: Event,
imports: [privacy.avsc] //it also imports the privacy schemas
fields: [{
name: privacy,
type: [ null, Privacy], //use imported Privacy type
default: Public
}
]
}
{code}
IDL files are able to import external schemas and protocols and it would be
very beneficial if schema files could import other schema files.
--
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
[jira] [Commented] (AVRO-1186) Java Annotations via IDL
[
https://issues.apache.org/jira/browse/AVRO-1186?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13489007#comment-13489007
]
Sharmarke Aden commented on AVRO-1186:
--
Wow, that was really quick. Thank you so much and keep up the great work.
Java Annotations via IDL
Key: AVRO-1186
URL: https://issues.apache.org/jira/browse/AVRO-1186
Project: Avro
Issue Type: New Feature
Components: java
Reporter: Sharmarke Aden
Assignee: Doug Cutting
Fix For: 1.7.3
Attachments: AVRO-1186.patch, AVRO-1186.patch
We would like to have the ability to add Java annotations to fields in the
Avro IDL (i.e. JSR 303 Bean Validation annotations). From a protocol stand
point these annotations may not mean much (or could they?) but from the
application stand point having this feature would allow developers to use
Avro generated beans application wide. From view layer all the way to the
data layer. To support this feature an IDL file could look something like
this:
{code}
@namespace(test.annotations)
protocol TestProto {
record User {
//declare the annotations that are imported in the generated record class
@header{
import org.hibernate.validator.constraints.NotBlank;
import org.hibernate.validator.constraints.Email;
}
//for each field one can specify an annotation they would like to use.
@{@NotBlank} string username;
string password;
@{@Email} string email;
}
}
{code}
The above IDL would generate a Java class that looks something like this:
{code}
/**
* Autogenerated by Avro
*
* DO NOT EDIT DIRECTLY
*/
package com.simvia.mode.avro;
import org.hibernate.validator.constraints.NotBlank;
import org.hibernate.validator.constraints.Email;
@SuppressWarnings(all)
public class User extends org.apache.avro.specific.SpecificRecordBase
implements org.apache.avro.specific.SpecificRecord {
...
@Deprecated @NotBlank public java.lang.CharSequence username;
@Deprecated public java.lang.CharSequence password;
@Deprecated @Email public java.lang.CharSequence email;
...
}
{code}
Perhaps this is too language specific but IMO the benefits of this feature in
the Java world is worth the effort and the exception.
--
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
[jira] [Created] (AVRO-1186) Java Annotations via IDL
Sharmarke Aden created AVRO-1186:
Summary: Java Annotations via IDL
Key: AVRO-1186
URL: https://issues.apache.org/jira/browse/AVRO-1186
Project: Avro
Issue Type: New Feature
Reporter: Sharmarke Aden
We would like to have the ability to add Java annotations to fields in the Avro
IDL (i.e. JSR 303 Bean Validation annotations). From a protocol stand point
these annotations may not mean much (or could they?) but from the application
stand point having this feature would allow developers to use Avro generated
beans application wide. From view layer all the way to the data layer. To
support this feature an IDL file could look something like this:
{code}
@namespace(test.annotations)
protocol TestProto {
record User {
//declare the annotations that are imported in the generated record class
@header{
import org.hibernate.validator.constraints.NotBlank;
import org.hibernate.validator.constraints.Email;
}
//for each field one can specify an annotation they would like to use.
@{@NotBlank} string username;
string password;
@{@Email} string email;
}
}
{code}
The above IDL would generate a Java class that looks something like this:
{code}
/**
* Autogenerated by Avro
*
* DO NOT EDIT DIRECTLY
*/
package com.simvia.mode.avro;
import org.hibernate.validator.constraints.NotBlank;
import org.hibernate.validator.constraints.Email;
@SuppressWarnings(all)
public class User extends org.apache.avro.specific.SpecificRecordBase
implements org.apache.avro.specific.SpecificRecord {
...
@Deprecated @NotBlank public java.lang.CharSequence username;
@Deprecated public java.lang.CharSequence password;
@Deprecated @Email public java.lang.CharSequence email;
...
}
{code}
Perhaps this is too language specific but IMO the benefits of this feature in
the Java world is worth the effort and the exception.
--
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
[jira] [Updated] (AVRO-1186) Java Annotations via IDL
[
https://issues.apache.org/jira/browse/AVRO-1186?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sharmarke Aden updated AVRO-1186:
-
Description:
We would like to have the ability to add Java annotations to fields in the Avro
IDL (i.e. JSR 303 Bean Validation annotations). From a protocol stand point
these annotations may not mean much (or could they?) but from the application
stand point having this feature would allow developers to use Avro generated
beans application wide. From view layer all the way to the data layer. To
support this feature an IDL file could look something like this:
{code}
@namespace(test.annotations)
protocol TestProto {
record User {
//declare the annotations that are imported in the generated record class
@header{
import org.hibernate.validator.constraints.NotBlank;
import org.hibernate.validator.constraints.Email;
}
//for each field one can specify an annotation they would like to use.
@{@NotBlank} string username;
string password;
@{@Email} string email;
}
}
{code}
The above IDL would generate a Java class that looks something like this:
{code}
/**
* Autogenerated by Avro
*
* DO NOT EDIT DIRECTLY
*/
package com.simvia.mode.avro;
import org.hibernate.validator.constraints.NotBlank;
import org.hibernate.validator.constraints.Email;
@SuppressWarnings(all)
public class User extends org.apache.avro.specific.SpecificRecordBase
implements org.apache.avro.specific.SpecificRecord {
...
@Deprecated @NotBlank public java.lang.CharSequence username;
@Deprecated public java.lang.CharSequence password;
@Deprecated @Email public java.lang.CharSequence email;
...
}
{code}
Perhaps this is too language specific but IMO the benefits of this feature in
the Java world is worth the effort and the exception.
was:
We would like to have the ability to add Java annotations to fields in the Avro
IDL (i.e. JSR 303 Bean Validation annotations). From a protocol stand point
these annotations may not mean much (or could they?) but from the application
stand point having this feature would allow developers to use Avro generated
beans application wide. From view layer all the way to the data layer. To
support this feature an IDL file could look something like this:
{code}
@namespace(test.annotations)
protocol TestProto {
record User {
//declare the annotations that are imported in the generated record class
@header{
import org.hibernate.validator.constraints.NotBlank;
import org.hibernate.validator.constraints.Email;
}
//for each field one can specify an annotation they would like to use.
@{@NotBlank} string username;
string password;
@{@Email} string email;
}
}
{code}
The above IDL would generate a Java class that looks something like this:
{code}
/**
* Autogenerated by Avro
*
* DO NOT EDIT DIRECTLY
*/
package com.simvia.mode.avro;
import org.hibernate.validator.constraints.NotBlank;
import org.hibernate.validator.constraints.Email;
@SuppressWarnings(all)
public class User extends org.apache.avro.specific.SpecificRecordBase
implements org.apache.avro.specific.SpecificRecord {
...
@Deprecated @NotBlank public java.lang.CharSequence username;
@Deprecated public java.lang.CharSequence password;
@Deprecated @Email public java.lang.CharSequence email;
...
}
{code}
Perhaps this is too language specific but IMO the benefits of this feature in
the Java world is worth the effort and the exception.
Java Annotations via IDL
Key: AVRO-1186
URL: https://issues.apache.org/jira/browse/AVRO-1186
Project: Avro
Issue Type: New Feature
Reporter: Sharmarke Aden
We would like to have the ability to add Java annotations to fields in the
Avro IDL (i.e. JSR 303 Bean Validation annotations). From a protocol stand
point these annotations may not mean much (or could they?) but from the
application stand point having this feature would allow developers to use
Avro generated beans application wide. From view layer all the way to the
data layer. To support this feature an IDL file could look something like
this:
{code}
@namespace(test.annotations)
protocol TestProto {
record User {
//declare the annotations that are imported in the generated record class
@header{
import org.hibernate.validator.constraints.NotBlank;
import org.hibernate.validator.constraints.Email;
}
//for each field one can specify an annotation they would like to use.
@{@NotBlank} string username;
string password;
@{@Email} string email;
}
}
{code}
The above IDL would generate a Java class that looks something like this:
{code}
/**
* Autogenerated by Avro
*
* DO NOT EDIT DIRECTLY
*/
package
[jira] [Commented] (AVRO-1186) Java Annotations via IDL
[
https://issues.apache.org/jira/browse/AVRO-1186?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13487106#comment-13487106
]
Sharmarke Aden commented on AVRO-1186:
--
This is perfect. What about also adding record/class level annotations support?
For example:
{code}
@javaAnnotation(com.company.MyClassAnnotation)
record User {
@javaAnnotation(org.hibernate.validator.constraints.NotBlank) string
username;
}
{code}
For multiple:
{code}
@javaAnnotation([Deprecated, com.company.MyClassAnnotation])
record User {
@javaAnnotations([Deprecated,
org.hibernate.validator.constraints.NotBlank])
string username;
}
{code}
Java Annotations via IDL
Key: AVRO-1186
URL: https://issues.apache.org/jira/browse/AVRO-1186
Project: Avro
Issue Type: New Feature
Reporter: Sharmarke Aden
We would like to have the ability to add Java annotations to fields in the
Avro IDL (i.e. JSR 303 Bean Validation annotations). From a protocol stand
point these annotations may not mean much (or could they?) but from the
application stand point having this feature would allow developers to use
Avro generated beans application wide. From view layer all the way to the
data layer. To support this feature an IDL file could look something like
this:
{code}
@namespace(test.annotations)
protocol TestProto {
record User {
//declare the annotations that are imported in the generated record class
@header{
import org.hibernate.validator.constraints.NotBlank;
import org.hibernate.validator.constraints.Email;
}
//for each field one can specify an annotation they would like to use.
@{@NotBlank} string username;
string password;
@{@Email} string email;
}
}
{code}
The above IDL would generate a Java class that looks something like this:
{code}
/**
* Autogenerated by Avro
*
* DO NOT EDIT DIRECTLY
*/
package com.simvia.mode.avro;
import org.hibernate.validator.constraints.NotBlank;
import org.hibernate.validator.constraints.Email;
@SuppressWarnings(all)
public class User extends org.apache.avro.specific.SpecificRecordBase
implements org.apache.avro.specific.SpecificRecord {
...
@Deprecated @NotBlank public java.lang.CharSequence username;
@Deprecated public java.lang.CharSequence password;
@Deprecated @Email public java.lang.CharSequence email;
...
}
{code}
Perhaps this is too language specific but IMO the benefits of this feature in
the Java world is worth the effort and the exception.
--
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
