*Sent:* Wednesday, February 8, 2017 10:37 AM
> *To:* user@avro.apache.org
> *Subject:* Avro C++ library potential bug in union type
>
> Hello Community,
>
> We are currently working on integrating avro into our products. We are
> exciting about avro's schema evolution feat
:37 AM
To: user@avro.apache.org
Subject: Avro C++ library potential bug in union type
Hello Community,
We are currently working on integrating avro into our products. We are exciting
about avro's schema evolution feature however we found in avro-cpp library it
didn't support it very well in old ve
Hello Community,
We are currently working on integrating avro into our products. We are
exciting about avro's schema evolution feature however we found in avro-cpp
library it didn't support it very well in old versions (1.7.0 which are
what we used before)
I found some JIRAs(AVRO-1360
According to the documentation:
https://avro.apache.org/docs/current/api/cpp/html/classavro_1_1GenericDatum.html#a879e7b725023bfd8246e15f07cb5bef0
avro::GenericDatum::GenericDatum( const
ValidSchemahttps://avro.apache.org/docs/current/api/cpp/html/classavro_1_1ValidSchema.html
I had filed a bug (Avrogen doesn't create the RPC methods from .avrp files
https://issues.apache.org/jira/browse/AVRO-1423 ) on the morning of Dec
31st before calling it an early day . Understandably nobody else looked at
the bug over the new year but I just checked today and it's still stagnant
1.5.4. For the older versions of
avro, input.position() is set to the end of the input data. Is there anybody
knows why this gets set to 0? Or is this a bug?
Ey-Chih Chow
. For the older versions
of avro, input.position() is set to the end of the input data. Is there
anybody knows why this gets set to 0? Or is this a bug?
Ey-Chih Chow
when map() gets invoked. With this, we can not extract data from
input. This is for the version of avro 1.5.4. For the older versions of avro,
input.position() is set to the end of the input data. Is there anybody knows
why this gets set to 0? Or is this a bug?
Ey-Chih Chow
the capacity
of the underlying buffer as opposed to compacting it.
So I think the code could be fixed by replacing get with
byteBufferValue.get(bytesCopy, 0 , byteBufferValue.limit());
Before I file a bug is there anything I'm missing?
J
Jira ticket filed...
https://issues.apache.org/jira/browse/AVRO-1036
I have a solution (added to comments on the ticket) but not sure it's
the best solution.
Thanks,
George
On 2/22/12 2:17 PM, Doug Cutting wrote:
On 02/22/2012 11:08 AM, George Fletcher wrote:
I'll file a bug and upload
It appears that AVRO 1.6.2 broked nested IDL imports. Our project is set
up as follows. We use the IDL for all protocol and type definitions. In
order to share types, we create empty avdl protocol files and name
them like A_Protocol and A_Protocol_Types.avdl. That ways protocol B
which might
It turns out there is a bug in the idl.jj compiler which doesn't pass
along the current sourceDirectory to 2nd level nested imports. I'll
file a bug and upload a patch and associated test. Any chance we can
spin 1.6.3 really fast?
I tried adding a jar of the avdl files as a dependency
On 02/22/2012 11:08 AM, George Fletcher wrote:
I'll file a bug and upload a patch and associated test.
Great! I'll watch for it. Thanks!
Any chance we can spin 1.6.3 really fast?
Probably. There were a few other things that I think folks wanted to
get in to a 1.6.3, but no one has yet
Looks like a bug to me.
Can you file a JIRA ticket?
Thanks!
On 8/29/11 1:24 PM, Yang tedd...@gmail.com wrote:
if I read on a empty file with BinaryDecoder, I get EOF, good,
but with the current code, if I read it again with the same decoder, I
get a IndexOutofBoundException, not EOF
yes https://issues.apache.org/jira/browse/AVRO-882
On Wed, Aug 31, 2011 at 6:52 PM, Scott Carey scottca...@apache.org wrote:
Looks like a bug to me.
Can you file a JIRA ticket?
Thanks!
On 8/29/11 1:24 PM, Yang tedd...@gmail.com wrote:
if I read on a empty file with BinaryDecoder, I
if I read on a empty file with BinaryDecoder, I get EOF, good,
but with the current code, if I read it again with the same decoder, I
get a IndexOutofBoundException, not EOF.
it seems that always giving EOF should be a more desirable behavior.
you can see from this test code:
import static
Sorry, my bad. I've uploaded a patch at
https://issues.apache.org/jira/browse/AVRO-845, my *guess* it'll be
merged soon.
On Sat, Jun 25, 2011 at 9:42 AM, Jeremy Lewi jer...@lewi.us wrote:
Hi,
I think the current version of setup.py is assuming you are using python
2.7 or later.
Line 24 is
Can anybody tell me if this this a bug? We use avro map/reduce API v 1.4 in
all of our code. Some of the jobs show weird behavior. We want to know if
this is fixable. Otherwise, we have to take out all the avro APIs and use the
conventional MR APIs instead.
Ey-Chih Chow
From: eyc
if this this a bug? We use avro map/reduce API v 1.4 in
all of our code. Some of the jobs show weird behavior. We want to know if
this is fixable. Otherwise, we have to take out all the avro APIs and use the
conventional MR APIs instead.
Ey-Chih Chow
From: eyc
I did some more investigation. I found weird behavior in the readString()
method of BinaryDecoder.java in Avro source code if we have the statement
record.put(rowkey, key) in the reduce() method. Does this mean that there is
a bug in BinaryDecoder.java ? Thanks.
Ey-Chih Chow
From: eyc
Hi,
I am working on an Avro MR job and encountering an issue with AvroReducerUtf8,
GenericRecord, GenericRecord. The corresponding reduce() routine is
implemented in the following way:
public void reduce(Utf8 key, IterableGenericRecord values,
AvroCollectorGenericRecord collector, Reporter
iterators or Avro deserialization code? Thanks.
Ey-Chih Chow
From: eyc...@hotmail.com
To: user@avro.apache.org
Subject: is this a bug?
Date: Wed, 2 Mar 2011 13:05:55 -0800
Hi,
I am working on an Avro MR job and encountering an issue with AvroReducerUtf8,
GenericRecord, GenericRecord
22 matches
Mail list logo
