Re: Need review/merges for couple of pull requests

[S G]

Thanks RB,

But I am not sure I follow that example (Probably because there is no
actual datum class there?).

Consider a complex code running in production with lots of circular
references.
Something like:

class Home {
   String address;
   Integer zipCode;
   List  residents;
}

class Person {
String name;
Person spouse;
House home;
Map  vehiclesOwned;
}

class Car {
 String make;
 Integer year;
 Dealer soldBy;
 Person ownedBy;
}

class Dealer {
String name;
String address;
List vehiclesSold;
}

The above is a made-up example, intentionally using easy-to-understand
references.
But it does show that circular references can become very complex and
across multiple chains.

If users have to write Conversion classes for all of the above along with
hash-map(s) that finds out IDs for the objects seen already,  writes them
out as separate fields and then reads them back to replace them with actual
objects, then it would be expecting too much from our clients IMO.

Perhaps it would be more helpful if there was a more seamless way of
getting this done automatically.

SG



On Wed, Jun 1, 2016 at 5:22 PM, Ryan Blue  wrote:

> Those aren't the datum classes, those are logical types that are added to
> the schema for your datum classes. The "referenceable" logical type is
> applied to the class that gets replaced with an ID reference and points to
> the field to use for that ID. The "reference" logical type is applied to
> the class that contains a referencable datum. Then there are conversions
> that replace a referenceable with its ID.
>
> On Wed, Jun 1, 2016 at 4:52 PM, S G  wrote:
>
> > RB,
> >
> > The test TestCircularReferences shows that the classes having circular
> > reference need to extend LogicalType.
> > If every circular reference class has to do this, then I think this would
> > be a big limitation for actual classes used in production code because
> they
> > would be already extending other classes plus asking several other teams
> to
> > change their base-class would be difficult.
> > Is there a way to do this without making the classes extend the
> LogicalType
> > ?
> >
> > SG
> >
> >
> > On Wed, Jun 1, 2016 at 3:29 PM, Ryan Blue 
> > wrote:
> >
> > > SG,
> > >
> > > The example/test I built uses logical types to remove the circular
> > > reference when writing and restore it when reading. It doesn't look
> like
> > > your test adds logical types, so that's probably the issue.
> > >
> > > rb
> > >
> > > On Wed, Jun 1, 2016 at 1:51 PM, S G  wrote:
> > >
> > > > Hey RB,
> > > >
> > > > I was trying out the circular refs with latest 1.8.1 version of Avro
> > and
> > > it
> > > > doesn't seem to be working out of the box for me.
> > > > Perhaps I am missing something and would appreciate your help.
> > > >
> > > > Thanks,
> > > > SG
> > > >
> > > >
> > > > Here is my test code:
> > > >
> > > > public class CircularRefsTest
> > > > {
> > > > @Test
> > > > public void testSerialization() throws Exception
> > > > {
> > > > // Create a circular linked-list
> > > > ListNode first = new ListNode("first");
> > > > ListNode second = new ListNode("second");
> > > > second.next = first;
> > > > first.next = second;
> > > >
> > > > ReflectData rdata = ReflectData.AllowNull.get();
> > > >
> > > > // Print Schema
> > > > Schema schema = rdata.getSchema(ListNode.class);
> > > > System.out.println(schema);
> > > >
> > > > // Serialize
> > > > DatumWriter datumWriter = new
> > > > ReflectDatumWriter(ListNode.class);
> > > > ByteArrayOutputStream byteArrayOutputStream = new
> > > > ByteArrayOutputStream();
> > > > Encoder encoder =
> > > > EncoderFactory.get().binaryEncoder(byteArrayOutputStream, null);
> > > > datumWriter.write(first, encoder);
> > > > encoder.flush();
> > > > byte[] bytes = byteArrayOutputStream.toByteArray();
> > > >
> > > > assertTrue( bytes != null );
> > > > }
> > > > }
> > > >
> > > > class ListNode
> > > > {
> > > > String data;
> > > > ListNode next;
> > > >
> > > > public ListNode() {
> > > > }
> > > > public ListNode(String data) {
> > > > this.data = data;
> > > > }
> > > > }
> > > >
> > > >
> > > >
> > > > On Thu, May 28, 2015 at 11:00 AM, Ryan Blue 
> wrote:
> > > >
> > > > > SG,
> > > > >
> > > > > The data ends up looking like this:
> > > > >
> > > > > {"id":1,"p":"parent data!","child":{"c":"child
> > > > data!","parent":{"long":1}}}
> > > > >
> > > > > I produced that with avro-tools 1.7.6 and tojson.
> > > > >
> > > > > Here's the schema: {
> > > > >   "type" : "record",
> > > > >   "name" : "Parent",
> > > > >   "fields" : [ {
> > > > > "name" : "id",
> > > > > "type" : "long"
> > > > >   }, {
> > > > > 

Re: Need review/merges for couple of pull requests

[Ryan Blue]

Those aren't the datum classes, those are logical types that are added to
the schema for your datum classes. The "referenceable" logical type is
applied to the class that gets replaced with an ID reference and points to
the field to use for that ID. The "reference" logical type is applied to
the class that contains a referencable datum. Then there are conversions
that replace a referenceable with its ID.

On Wed, Jun 1, 2016 at 4:52 PM, S G  wrote:

> RB,
>
> The test TestCircularReferences shows that the classes having circular
> reference need to extend LogicalType.
> If every circular reference class has to do this, then I think this would
> be a big limitation for actual classes used in production code because they
> would be already extending other classes plus asking several other teams to
> change their base-class would be difficult.
> Is there a way to do this without making the classes extend the LogicalType
> ?
>
> SG
>
>
> On Wed, Jun 1, 2016 at 3:29 PM, Ryan Blue 
> wrote:
>
> > SG,
> >
> > The example/test I built uses logical types to remove the circular
> > reference when writing and restore it when reading. It doesn't look like
> > your test adds logical types, so that's probably the issue.
> >
> > rb
> >
> > On Wed, Jun 1, 2016 at 1:51 PM, S G  wrote:
> >
> > > Hey RB,
> > >
> > > I was trying out the circular refs with latest 1.8.1 version of Avro
> and
> > it
> > > doesn't seem to be working out of the box for me.
> > > Perhaps I am missing something and would appreciate your help.
> > >
> > > Thanks,
> > > SG
> > >
> > >
> > > Here is my test code:
> > >
> > > public class CircularRefsTest
> > > {
> > > @Test
> > > public void testSerialization() throws Exception
> > > {
> > > // Create a circular linked-list
> > > ListNode first = new ListNode("first");
> > > ListNode second = new ListNode("second");
> > > second.next = first;
> > > first.next = second;
> > >
> > > ReflectData rdata = ReflectData.AllowNull.get();
> > >
> > > // Print Schema
> > > Schema schema = rdata.getSchema(ListNode.class);
> > > System.out.println(schema);
> > >
> > > // Serialize
> > > DatumWriter datumWriter = new
> > > ReflectDatumWriter(ListNode.class);
> > > ByteArrayOutputStream byteArrayOutputStream = new
> > > ByteArrayOutputStream();
> > > Encoder encoder =
> > > EncoderFactory.get().binaryEncoder(byteArrayOutputStream, null);
> > > datumWriter.write(first, encoder);
> > > encoder.flush();
> > > byte[] bytes = byteArrayOutputStream.toByteArray();
> > >
> > > assertTrue( bytes != null );
> > > }
> > > }
> > >
> > > class ListNode
> > > {
> > > String data;
> > > ListNode next;
> > >
> > > public ListNode() {
> > > }
> > > public ListNode(String data) {
> > > this.data = data;
> > > }
> > > }
> > >
> > >
> > >
> > > On Thu, May 28, 2015 at 11:00 AM, Ryan Blue  wrote:
> > >
> > > > SG,
> > > >
> > > > The data ends up looking like this:
> > > >
> > > > {"id":1,"p":"parent data!","child":{"c":"child
> > > data!","parent":{"long":1}}}
> > > >
> > > > I produced that with avro-tools 1.7.6 and tojson.
> > > >
> > > > Here's the schema: {
> > > >   "type" : "record",
> > > >   "name" : "Parent",
> > > >   "fields" : [ {
> > > > "name" : "id",
> > > > "type" : "long"
> > > >   }, {
> > > > "name" : "p",
> > > > "type" : "string"
> > > >   }, {
> > > > "name" : "child",
> > > > "type" : {
> > > >   "type" : "record",
> > > >   "name" : "Child",
> > > >   "fields" : [ {
> > > > "name" : "c",
> > > > "type" : "string"
> > > >   }, {
> > > > "name" : "parent",
> > > > "type" : [ "null", "long", "Parent" ]
> > > >   } ],
> > > >   "logicalType" : "reference",
> > > >   "ref-field-name" : "parent"
> > > > }
> > > >   } ],
> > > >   "logicalType" : "referenceable",
> > > >   "id-field-name" : "id"
> > > > }
> > > >
> > > > rb
> > > >
> > > >
> > > > On 05/28/2015 09:50 AM, S G wrote:
> > > >
> > > >> RB,
> > > >>
> > > >> Could you please attach the schema and the JSON serialized output
> from
> > > >> your
> > > >> test-code as well?
> > > >> My build environment is currently broken as I am grappling with some
> > > Java
> > > >> 8
> > > >> update issues.
> > > >>
> > > >> Thanks
> > > >> SG
> > > >>
> > > >>
> > > >> On Wed, May 27, 2015 at 3:28 PM, Ryan Blue 
> wrote:
> > > >>
> > > >> SG,
> > > >>>
> > > >>> Now that logical types are in, I had some time to look at this
> issue.
> > > >>> Thanks for your patience on this.
> > > >>>
> > > >>> When I started looking at the use case, this began to look very
> much
> > > like
> > > >>> a logical type issue. (I know, I've been saying that a lot.) When
> you
> > > >>> write, you replace 

Re: Need review/merges for couple of pull requests

[S G]

RB,

The test TestCircularReferences shows that the classes having circular
reference need to extend LogicalType.
If every circular reference class has to do this, then I think this would
be a big limitation for actual classes used in production code because they
would be already extending other classes plus asking several other teams to
change their base-class would be difficult.
Is there a way to do this without making the classes extend the LogicalType
?

SG


On Wed, Jun 1, 2016 at 3:29 PM, Ryan Blue  wrote:

> SG,
>
> The example/test I built uses logical types to remove the circular
> reference when writing and restore it when reading. It doesn't look like
> your test adds logical types, so that's probably the issue.
>
> rb
>
> On Wed, Jun 1, 2016 at 1:51 PM, S G  wrote:
>
> > Hey RB,
> >
> > I was trying out the circular refs with latest 1.8.1 version of Avro and
> it
> > doesn't seem to be working out of the box for me.
> > Perhaps I am missing something and would appreciate your help.
> >
> > Thanks,
> > SG
> >
> >
> > Here is my test code:
> >
> > public class CircularRefsTest
> > {
> > @Test
> > public void testSerialization() throws Exception
> > {
> > // Create a circular linked-list
> > ListNode first = new ListNode("first");
> > ListNode second = new ListNode("second");
> > second.next = first;
> > first.next = second;
> >
> > ReflectData rdata = ReflectData.AllowNull.get();
> >
> > // Print Schema
> > Schema schema = rdata.getSchema(ListNode.class);
> > System.out.println(schema);
> >
> > // Serialize
> > DatumWriter datumWriter = new
> > ReflectDatumWriter(ListNode.class);
> > ByteArrayOutputStream byteArrayOutputStream = new
> > ByteArrayOutputStream();
> > Encoder encoder =
> > EncoderFactory.get().binaryEncoder(byteArrayOutputStream, null);
> > datumWriter.write(first, encoder);
> > encoder.flush();
> > byte[] bytes = byteArrayOutputStream.toByteArray();
> >
> > assertTrue( bytes != null );
> > }
> > }
> >
> > class ListNode
> > {
> > String data;
> > ListNode next;
> >
> > public ListNode() {
> > }
> > public ListNode(String data) {
> > this.data = data;
> > }
> > }
> >
> >
> >
> > On Thu, May 28, 2015 at 11:00 AM, Ryan Blue  wrote:
> >
> > > SG,
> > >
> > > The data ends up looking like this:
> > >
> > > {"id":1,"p":"parent data!","child":{"c":"child
> > data!","parent":{"long":1}}}
> > >
> > > I produced that with avro-tools 1.7.6 and tojson.
> > >
> > > Here's the schema: {
> > >   "type" : "record",
> > >   "name" : "Parent",
> > >   "fields" : [ {
> > > "name" : "id",
> > > "type" : "long"
> > >   }, {
> > > "name" : "p",
> > > "type" : "string"
> > >   }, {
> > > "name" : "child",
> > > "type" : {
> > >   "type" : "record",
> > >   "name" : "Child",
> > >   "fields" : [ {
> > > "name" : "c",
> > > "type" : "string"
> > >   }, {
> > > "name" : "parent",
> > > "type" : [ "null", "long", "Parent" ]
> > >   } ],
> > >   "logicalType" : "reference",
> > >   "ref-field-name" : "parent"
> > > }
> > >   } ],
> > >   "logicalType" : "referenceable",
> > >   "id-field-name" : "id"
> > > }
> > >
> > > rb
> > >
> > >
> > > On 05/28/2015 09:50 AM, S G wrote:
> > >
> > >> RB,
> > >>
> > >> Could you please attach the schema and the JSON serialized output from
> > >> your
> > >> test-code as well?
> > >> My build environment is currently broken as I am grappling with some
> > Java
> > >> 8
> > >> update issues.
> > >>
> > >> Thanks
> > >> SG
> > >>
> > >>
> > >> On Wed, May 27, 2015 at 3:28 PM, Ryan Blue  wrote:
> > >>
> > >> SG,
> > >>>
> > >>> Now that logical types are in, I had some time to look at this issue.
> > >>> Thanks for your patience on this.
> > >>>
> > >>> When I started looking at the use case, this began to look very much
> > like
> > >>> a logical type issue. (I know, I've been saying that a lot.) When you
> > >>> write, you replace any referenced object with its id. When you read,
> > you
> > >>> replace those ids with the correct object. I went ahead and
> implemented
> > >>> this using 2 logical types: Referenceable for an object with an id,
> and
> > >>> Reference for a record with a field that references another object by
> > id.
> > >>>
> > >>> There were some trade-offs to this approach. For example, I had to
> use
> > a
> > >>> logical type for the object containing the reference rather than for
> > the
> > >>> reference itself because I used a callback to set the object once it
> is
> > >>> found. That happens because children with references to a parent are
> > >>> deserialized completely first. The parent is the last object to be
> > >>> assembled and passed to the logical type conversion.
> > >>>
> > >>> A 

[jira] [Commented] (AVRO-1847) IDL compiler uses ByteBuffer for decimal type even if logical type is supported

[Yibing Shi (JIRA)]

[ 
https://issues.apache.org/jira/browse/AVRO-1847?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15311336#comment-15311336
 ] 

Yibing Shi commented on AVRO-1847:
--

Understood! Thanks for the response!

> IDL compiler uses ByteBuffer for decimal type even if logical type is 
> supported 
> 
>
> Key: AVRO-1847
> URL: https://issues.apache.org/jira/browse/AVRO-1847
> Project: Avro
>  Issue Type: Bug
>  Components: java
>Affects Versions: 1.8.0
>Reporter: Yibing Shi
> Attachments: AVRO-1847.1.patch, AVRO-1847.2.patch
>
>
> Version 1.8.0 has added the support of logical types. A conversion class 
> (Conversions.DecimalConversion) has also been added for decimal type. 
> However, the IDL compiler still uses ByteBuffer for decimal types, which is 
> not the same behaviour as data, time or timestamp type (added in AVRO-1684). 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Re: Need review/merges for couple of pull requests

[Ryan Blue]

SG,

The example/test I built uses logical types to remove the circular
reference when writing and restore it when reading. It doesn't look like
your test adds logical types, so that's probably the issue.

rb

On Wed, Jun 1, 2016 at 1:51 PM, S G  wrote:

> Hey RB,
>
> I was trying out the circular refs with latest 1.8.1 version of Avro and it
> doesn't seem to be working out of the box for me.
> Perhaps I am missing something and would appreciate your help.
>
> Thanks,
> SG
>
>
> Here is my test code:
>
> public class CircularRefsTest
> {
> @Test
> public void testSerialization() throws Exception
> {
> // Create a circular linked-list
> ListNode first = new ListNode("first");
> ListNode second = new ListNode("second");
> second.next = first;
> first.next = second;
>
> ReflectData rdata = ReflectData.AllowNull.get();
>
> // Print Schema
> Schema schema = rdata.getSchema(ListNode.class);
> System.out.println(schema);
>
> // Serialize
> DatumWriter datumWriter = new
> ReflectDatumWriter(ListNode.class);
> ByteArrayOutputStream byteArrayOutputStream = new
> ByteArrayOutputStream();
> Encoder encoder =
> EncoderFactory.get().binaryEncoder(byteArrayOutputStream, null);
> datumWriter.write(first, encoder);
> encoder.flush();
> byte[] bytes = byteArrayOutputStream.toByteArray();
>
> assertTrue( bytes != null );
> }
> }
>
> class ListNode
> {
> String data;
> ListNode next;
>
> public ListNode() {
> }
> public ListNode(String data) {
> this.data = data;
> }
> }
>
>
>
> On Thu, May 28, 2015 at 11:00 AM, Ryan Blue  wrote:
>
> > SG,
> >
> > The data ends up looking like this:
> >
> > {"id":1,"p":"parent data!","child":{"c":"child
> data!","parent":{"long":1}}}
> >
> > I produced that with avro-tools 1.7.6 and tojson.
> >
> > Here's the schema: {
> >   "type" : "record",
> >   "name" : "Parent",
> >   "fields" : [ {
> > "name" : "id",
> > "type" : "long"
> >   }, {
> > "name" : "p",
> > "type" : "string"
> >   }, {
> > "name" : "child",
> > "type" : {
> >   "type" : "record",
> >   "name" : "Child",
> >   "fields" : [ {
> > "name" : "c",
> > "type" : "string"
> >   }, {
> > "name" : "parent",
> > "type" : [ "null", "long", "Parent" ]
> >   } ],
> >   "logicalType" : "reference",
> >   "ref-field-name" : "parent"
> > }
> >   } ],
> >   "logicalType" : "referenceable",
> >   "id-field-name" : "id"
> > }
> >
> > rb
> >
> >
> > On 05/28/2015 09:50 AM, S G wrote:
> >
> >> RB,
> >>
> >> Could you please attach the schema and the JSON serialized output from
> >> your
> >> test-code as well?
> >> My build environment is currently broken as I am grappling with some
> Java
> >> 8
> >> update issues.
> >>
> >> Thanks
> >> SG
> >>
> >>
> >> On Wed, May 27, 2015 at 3:28 PM, Ryan Blue  wrote:
> >>
> >> SG,
> >>>
> >>> Now that logical types are in, I had some time to look at this issue.
> >>> Thanks for your patience on this.
> >>>
> >>> When I started looking at the use case, this began to look very much
> like
> >>> a logical type issue. (I know, I've been saying that a lot.) When you
> >>> write, you replace any referenced object with its id. When you read,
> you
> >>> replace those ids with the correct object. I went ahead and implemented
> >>> this using 2 logical types: Referenceable for an object with an id, and
> >>> Reference for a record with a field that references another object by
> id.
> >>>
> >>> There were some trade-offs to this approach. For example, I had to use
> a
> >>> logical type for the object containing the reference rather than for
> the
> >>> reference itself because I used a callback to set the object once it is
> >>> found. That happens because children with references to a parent are
> >>> deserialized completely first. The parent is the last object to be
> >>> assembled and passed to the logical type conversion.
> >>>
> >>> A bigger issue was that logical types are currently conservative and
> >>> don't
> >>> overlap with reflect types or anything that sets java-class. That means
> >>> that this currently only works with generic types. But, I'd rather make
> >>> logical types work for reflect than add more custom code to support
> this.
> >>> Does that sound reasonable?
> >>>
> >>> I'm attaching a diff with the working test code so you can take a look
> at
> >>> the approach. Let me know what you are thinking.
> >>>
> >>> rb
> >>>
> >>> On 05/20/2015 12:05 PM, S G wrote:
> >>>
> >>> I am requesting some help with AVRO-695.
>  Here are some pieces from the last conversation.
> 
> 
>  Doug Cutting
>  
>  added
>  a comment - 02/Oct/14 21:19
> 
>  Here's a modified 

Re: Need review/merges for couple of pull requests

[S G]

Hey RB,

I was trying out the circular refs with latest 1.8.1 version of Avro and it
doesn't seem to be working out of the box for me.
Perhaps I am missing something and would appreciate your help.

Thanks,
SG


Here is my test code:

public class CircularRefsTest
{
@Test
public void testSerialization() throws Exception
{
// Create a circular linked-list
ListNode first = new ListNode("first");
ListNode second = new ListNode("second");
second.next = first;
first.next = second;

ReflectData rdata = ReflectData.AllowNull.get();

// Print Schema
Schema schema = rdata.getSchema(ListNode.class);
System.out.println(schema);

// Serialize
DatumWriter datumWriter = new
ReflectDatumWriter(ListNode.class);
ByteArrayOutputStream byteArrayOutputStream = new
ByteArrayOutputStream();
Encoder encoder =
EncoderFactory.get().binaryEncoder(byteArrayOutputStream, null);
datumWriter.write(first, encoder);
encoder.flush();
byte[] bytes = byteArrayOutputStream.toByteArray();

assertTrue( bytes != null );
}
}

class ListNode
{
String data;
ListNode next;

public ListNode() {
}
public ListNode(String data) {
this.data = data;
}
}



On Thu, May 28, 2015 at 11:00 AM, Ryan Blue  wrote:

> SG,
>
> The data ends up looking like this:
>
> {"id":1,"p":"parent data!","child":{"c":"child data!","parent":{"long":1}}}
>
> I produced that with avro-tools 1.7.6 and tojson.
>
> Here's the schema: {
>   "type" : "record",
>   "name" : "Parent",
>   "fields" : [ {
> "name" : "id",
> "type" : "long"
>   }, {
> "name" : "p",
> "type" : "string"
>   }, {
> "name" : "child",
> "type" : {
>   "type" : "record",
>   "name" : "Child",
>   "fields" : [ {
> "name" : "c",
> "type" : "string"
>   }, {
> "name" : "parent",
> "type" : [ "null", "long", "Parent" ]
>   } ],
>   "logicalType" : "reference",
>   "ref-field-name" : "parent"
> }
>   } ],
>   "logicalType" : "referenceable",
>   "id-field-name" : "id"
> }
>
> rb
>
>
> On 05/28/2015 09:50 AM, S G wrote:
>
>> RB,
>>
>> Could you please attach the schema and the JSON serialized output from
>> your
>> test-code as well?
>> My build environment is currently broken as I am grappling with some Java
>> 8
>> update issues.
>>
>> Thanks
>> SG
>>
>>
>> On Wed, May 27, 2015 at 3:28 PM, Ryan Blue  wrote:
>>
>> SG,
>>>
>>> Now that logical types are in, I had some time to look at this issue.
>>> Thanks for your patience on this.
>>>
>>> When I started looking at the use case, this began to look very much like
>>> a logical type issue. (I know, I've been saying that a lot.) When you
>>> write, you replace any referenced object with its id. When you read, you
>>> replace those ids with the correct object. I went ahead and implemented
>>> this using 2 logical types: Referenceable for an object with an id, and
>>> Reference for a record with a field that references another object by id.
>>>
>>> There were some trade-offs to this approach. For example, I had to use a
>>> logical type for the object containing the reference rather than for the
>>> reference itself because I used a callback to set the object once it is
>>> found. That happens because children with references to a parent are
>>> deserialized completely first. The parent is the last object to be
>>> assembled and passed to the logical type conversion.
>>>
>>> A bigger issue was that logical types are currently conservative and
>>> don't
>>> overlap with reflect types or anything that sets java-class. That means
>>> that this currently only works with generic types. But, I'd rather make
>>> logical types work for reflect than add more custom code to support this.
>>> Does that sound reasonable?
>>>
>>> I'm attaching a diff with the working test code so you can take a look at
>>> the approach. Let me know what you are thinking.
>>>
>>> rb
>>>
>>> On 05/20/2015 12:05 PM, S G wrote:
>>>
>>> I am requesting some help with AVRO-695.
 Here are some pieces from the last conversation.


 Doug Cutting
 
 added
 a comment - 02/Oct/14 21:19

 Here's a modified version of the patch. It moves all significant changes
 to
 reflect. Since reflect is the only implementation that can generate an
 appropriate schema, changes should be confined to there.

 The tests need to be updated, as they still assume generic.
 
 <

 https://issues.apache.org/jira/browse/AVRO-695?focusedCommentId=14286370=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14286370

>
> Sachin Goyal
 <
 

[jira] [Commented] (AVRO-1847) IDL compiler uses ByteBuffer for decimal type even if logical type is supported

[Ryan Blue (JIRA)]

[ 
https://issues.apache.org/jira/browse/AVRO-1847?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15310618#comment-15310618
 ] 

Ryan Blue commented on AVRO-1847:
-

Sorry, I haven't had time for an in-depth review of this lately. It is in the 
queue, but I can't say when I'll have time.

> IDL compiler uses ByteBuffer for decimal type even if logical type is 
> supported 
> 
>
> Key: AVRO-1847
> URL: https://issues.apache.org/jira/browse/AVRO-1847
> Project: Avro
>  Issue Type: Bug
>  Components: java
>Affects Versions: 1.8.0
>Reporter: Yibing Shi
> Attachments: AVRO-1847.1.patch, AVRO-1847.2.patch
>
>
> Version 1.8.0 has added the support of logical types. A conversion class 
> (Conversions.DecimalConversion) has also been added for decimal type. 
> However, the IDL compiler still uses ByteBuffer for decimal types, which is 
> not the same behaviour as data, time or timestamp type (added in AVRO-1684). 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (AVRO-1461) Distribute Perl API on CPAN

[Burak Gursoy (JIRA)]

[ 
https://issues.apache.org/jira/browse/AVRO-1461?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15310597#comment-15310597
 ] 

Burak Gursoy commented on AVRO-1461:


In addition to the above: you are also missing the automated regression tests 
done by the CPAN Testers which will test the distribution against a multitude 
of Perl versions on various OS/platforms.

> Distribute Perl API on CPAN
> ---
>
> Key: AVRO-1461
> URL: https://issues.apache.org/jira/browse/AVRO-1461
> Project: Avro
>  Issue Type: Wish
>  Components: perl
>Reporter: John Karp
>Priority: Minor
>
> Having a package for the Perl Avro API distributed on CPAN would increase the 
> visibility and convenience of the Avro project to the Perl world 
> significantly.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (AVRO-1461) Distribute Perl API on CPAN

[Ryan Blue (JIRA)]

[ 
https://issues.apache.org/jira/browse/AVRO-1461?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15310592#comment-15310592
 ] 

Ryan Blue commented on AVRO-1461:
-

Sounds good to me. Would someone like to find out what it takes to distribute a 
module on CPAN and explain the process here?

> Distribute Perl API on CPAN
> ---
>
> Key: AVRO-1461
> URL: https://issues.apache.org/jira/browse/AVRO-1461
> Project: Avro
>  Issue Type: Wish
>  Components: perl
>Reporter: John Karp
>Priority: Minor
>
> Having a package for the Perl Avro API distributed on CPAN would increase the 
> visibility and convenience of the Avro project to the Perl world 
> significantly.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[GitHub] avro pull request #99: Avro 1856 concat tool append to input

[MikeHurleySurescripts]

GitHub user MikeHurleySurescripts opened a pull request:

https://github.com/apache/avro/pull/99

Avro 1856 concat tool append to input

Let me know if this pull request should be pointed to a different branch.

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/MikeHurleySurescripts/avro 
AVRO-1856-ConcatTool-AppendToInput

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/avro/pull/99.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #99


commit def5dab27dbd1f17f9124df5845f469b5c7a8aa0
Author: Doug Cutting 
Date:   2014-07-18T18:39:09Z

Create tag for 1.7.7-rc0.

git-svn-id: 
https://svn.apache.org/repos/asf/avro/tags/release-1.7.7-rc0@1611761 
13f79535-47bb-0310-9956-ffa450edef68

commit f457317854f7111a8209111a9f573dae46704660
Author: Doug Cutting 
Date:   2014-07-18T19:13:46Z

Re-tag 1.7.7-rc0.

git-svn-id: 
https://svn.apache.org/repos/asf/avro/tags/release-1.7.7-rc0@1611774 
13f79535-47bb-0310-9956-ffa450edef68

commit b1e93f10a08ab95e79913580441f8a63c72dcc20
Author: Doug Cutting 
Date:   2014-07-24T18:49:05Z

Tag 1.7.7 release.

git-svn-id: 
https://svn.apache.org/repos/asf/avro/tags/release-1.7.7@1613244 
13f79535-47bb-0310-9956-ffa450edef68

commit 9e26d4d64202b61543af2c779a8be3b62307fa84
Author: Mike Hurley 
Date:   2016-05-31T13:33:03Z

AVRO-1856: updated ConcatTool to support appending to an input file instead 
of writing to a new output file

commit 8a21fab73a5e19d105e750496ca66b702b224da5
Author: Mike Hurley 
Date:   2016-06-01T14:44:22Z

Merge remote-tracking branch 'origin/branch-1.8' into 
AVRO-1856-ConcatTool-AppendToInput

# Conflicts:
#   lang/java/tools/src/main/java/org/apache/avro/tool/Util.java




---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---