n
> > on the PR <https://github.com/apache/avro/pull/2672>. There are also
> > implementations already for Java
> > <https://github.com/apache/avro/pull/2652> (thanks
> > Christophe!), and one for Rust (thanks Martin!). If there are no
> concerns,
> > I wou
pport for
> > nanosecond
> > > timestamps <https://github.com/apache/avro/pull/2608>. Next to that,
> > there
> > > is much more that I think would be great to get out to the public. I
> > would
> > > like to know if there is anything that you think should be included in
> > the
> > > release, so we can start planning the next release. Thoughts?
> > >
> > > Kind regards,
> > > Fokko
> > >
> >
>
--
Ryan Blue
Tabular
3Acomment-tabpanel=17770969#comment-17770969
> > > > > >
> > > > >
> > > > > So now, we can vote. Because a logo lasts longer than a typical
> > release,
> > > > > the rules deviate from the usual rules
> > > > > <https://www.apache.org/foundation/voting>:
> > > > >
> > > > >- the vote lasts 2 weeks
> > > > >- to avoid confusion, please vote with the V... ifentifier:
> V9.2,
> > V10.2,
> > > > >V11.2, V3.1
> > > > >- the winner is the logo with at least two (2) votes more than
> the
> > > > >runner-up
> > > > >- if there is no clear winner, we'll vote by simple majority
> > between the
> > > > >top picks
> > > > >
> > > > >
> > > > > Please vote for your preference!
> > > > >
> > > > >
> > > > > Kind regards,
> > > > > Oscar
> > > > >
> > > > > --
> > > > > ✉️ Oscar Westra van Holthe - Kind
> > > > > https://github.com/opwvhk/
> > > > >
> >
>
--
Ryan Blue
Tabular
may be that it requires a lot of footnotes and
> qualifications for differences in how languages implement the spec, but
> overall it would still be useful to identify gaps, highlight differences,
> and perhaps ultimately drive more compatibility.
>
--
Ryan Blue
Tabular
; > > together to complete the ASF IP Clearance process
> > > (http://incubator.apache.org/ip-clearance/) and import the Rust
> > > implementation
> > > into the Avro codebase.
> > >
> > > +1 : Accept contribution of Rust implementation
> > > 0 : No opinion
> > > -1 : Reject contribution because...
> > >
> > > Here is my vote: +1
> > >
> > > The vote will be open for at least 72 hours.
> > >
> > > Thanks,
> > > Ismaël
> > >
> >
>
--
Ryan Blue
cord type, when encoding the union?
>
> Similarly, I wonder about cases where multiple records are in a union.
> I think it's easy to imagine the ambiguous cases without spelling it
> all out.
>
> Maybe this ambiguity is specific to the Python implementation, I'm not
> sure.
>
--
Ryan Blue
Software Engineer
Netflix
[1]
> >
> https://lists.apache.org/thread.html/r2a175f8b96dd7a556cf1b7438a5c8efcacdd4a06080926142734%40%3Cdev.avro.apache.org%3E
> > > [2]
> >
> https://docs.github.com/en/free-pro-team@latest/github/collaborating-with-issues-and-pull-requests/automatically-merging-a-pull-request
> >
>
--
Ryan Blue
Software Engineer
Netflix
it tests.
> > > > - The slowest jobs (the Java tests) take 15 minutes. The worst case
> > > > test run (aside from an outage) will probably be under 20 minutes, if
> > > > we are heavily queued.
> > > > - This PR tests java 8 and 11, js using node 10, 11 and 12, php 7.3,
> > > > 7.4 and 8, python 3.6-3.9 and pypy3.6 and 3.7. Adding and removing
> > > > language implementations is trivial.
> > > > - If we merge this PR, anyone who forks the repo will get these
> > > > actions in their fork.
> > > >
> > > > One thing I haven't yet implemented is an action for
> > > > share/test/interop/bin/test_rpc_interop.sh. I think I can do that,
> > > > too, but I want to know if this can go anywhere before I work on it
> > > > more.
> > > >
> > > > WDYT?
> > > >
> > > > - Michael
> > > >
>
--
Ryan Blue
Software Engineer
Netflix
ere are the Apache Voting Rules:
> > http://www.apache.org/foundation/voting.html
> >
> > This vote will remain open for at least 72 hours, more probably until
> next
> > week.
> >
> > [ ] +1 Drop support for Python 2
> > [ ] +0
> > [ ] -1 Continue supporting Python 2 because/until…
> >
>
--
Ryan Blue
Software Engineer
Netflix
ant.
> > > > > >
> > > > > > And I agree that we should mainly focus on the Avro spec itself,
> and
> > > > not
> > > > > > too much on File I/O and Network etc :) However, if we decide to
> > > break
> > > > an
> > > > > > API, we should do it for a good reason.
> > > > > >
> > > > > > Cheers, Fokko
> > > > > >
> > > > > > Op wo 22 apr. 2020 om 16:09 schreef Andy Le :
> > > > > >
> > > > > > > Hi guys,
> > > > > > >
> > > > > > > I'm new to this vibrant open source community. My story with
> Avro
> > > > can be
> > > > > > > found here [1]
> > > > > > >
> > > > > > > While implementing the feature, I got stuck and had various
> > > > discussions
> > > > > > > with Dough Cutting, Fokko Driesprong You may see here [2]
> > > > > > >
> > > > > > > Here my (bias) observations about our current Avro 1.9.x:
> > > > > > >
> > > > > > > - Some improvements can't be made due to fear of backward
> > > > > > > incompatibilities. For example: specifications about named
> Union.
> > > > > > >
> > > > > > > - If `Apache Avro™ is a data serialization system.` then the
> > > > repository
> > > > > > > `apache/avro` should solely focus on (de)serialization, right?
> > > > Currently
> > > > > > > our repository contains many nice-to-have-but-not-critical
> things
> > > > like:
> > > > > > > File I/O, Network I/O
> > > > > > >
> > > > > > > IMHO, I think:
> > > > > > >
> > > > > > > - We should publicly gather RFCs for Avro 2.x
> > > > > > >
> > > > > > > - We should move such nice things out of Avro 2.x (may be to
> other
> > > > > > > dedicated repositories)
> > > > > > >
> > > > > > > What do you think about my suggestions. Pls kindly let me know.
> > > > > > >
> > > > > > > Thank you & be strong.
> > > > > > >
> > > > > > > [1] My fork:
> https://github.com/anhldbk/avro-fork#why-this-fork
> > > > > > > [2] My opened issue:
> > > > > > >
> > > >
> > >
> https://issues.apache.org/jira/browse/AVRO-2808?jql=reporter%3Danhldbk%20AND%20resolution%20is%20EMPTY
> > > > > > >
> > > > > > >
> > > > > > >
> > > >
> > >
> >
>
--
Ryan Blue
Software Engineer
Netflix
gt; > > - If `Apache Avro™ is a data serialization system.` then the
> repository
> > > > `apache/avro` should solely focus on (de)serialization, right?
> Currently
> > > > our repository contains many nice-to-have-but-not-critical things
> like:
> > > > File I/O, Network I/O
> > > >
> > > > IMHO, I think:
> > > >
> > > > - We should publicly gather RFCs for Avro 2.x
> > > >
> > > > - We should move such nice things out of Avro 2.x (may be to other
> > > > dedicated repositories)
> > > >
> > > > What do you think about my suggestions. Pls kindly let me know.
> > > >
> > > > Thank you & be strong.
> > > >
> > > > [1] My fork: https://github.com/anhldbk/avro-fork#why-this-fork
> > > > [2] My opened issue:
> > > >
> https://issues.apache.org/jira/browse/AVRO-2808?jql=reporter%3Danhldbk%20AND%20resolution%20is%20EMPTY
> > > >
> > > >
> > > >
>
--
Ryan Blue
Software Engineer
Netflix
ect read(Object old, Schema expected, ResolvingDecoder
> in)
> > throws IOException {
> > Object datum = this.readWithoutConversion(old, expected, in);
> > LogicalType logicalType = expected.getLogicalType();
> > if (logicalType != null) {
> > Conversion conversion =
> > this.getData().getConversionFor(logicalType);
> > if (conversion != null) {
> > return this.convert(datum, expected, logicalType,
> > conversion);
> > }
> > }
> >
> > return datum;
> > }
> >
> > public Conversion getConversionFor(LogicalType logicalType) {
> > return logicalType == null ? null :
> > (Conversion)this.conversions.get(logicalType.getName());
> > }
> >
> >
> > Thanks,
> > Csaba
> >
> >
> >
>
--
Ryan Blue
Software Engineer
Netflix
e
> plan is
> > > to
> > > > > > completely remove Joda from the codebase since it is officially
> > > > > deprecated
> > > > > > in favor of Java8 time (jsr310). A lot of this stuff is just
> changes
> > > to
> > > >
libraries
> and then have the docs for the libraries claim spec version
> compatibility?
>
> On Tue, Sep 10, 2019 at 3:55 PM Ryan Blue
> wrote:
> >
> > +1 for changing the version strings to follow a more standard convention.
> > We don't have any breaking format changes, so I
that had so much baggage) while we're trying to reestablish good
> habits on release cadence. How many major version are we planning to
> keep going once 1.10 is ready?
>
> What do folks think about starting a CONTRIBUTING.md with some of
> these expectations? Is there a better place to track it?
>
> [1] : https://s.apache.org/71yqv
>
--
Ryan Blue
Software Engineer
Netflix
f this feature.
> >
> > The specific proposal would be that Avro 1.9.x would refuse to accept
> > recursive records, and thus would not be able to read binary files
> > written by older versions of Avro. I haven't heard of anyone actually
> > using them, so I don't think this would be a problem.
> >
>
--
Ryan Blue
Software Engineer
Netflix
eturn ByteBuffer.wrap(value.unscaledValue().toByteArray());
> }
>
> but, I find that, nowhere two's-complement representation of the
> unscaled integer
> value in big-endian byte order is stored in byte array.
>
> Can anyone help me with this?
>
> Thanks,
>
> Indhumathi M
>
--
Ryan Blue
Software Engineer
Netflix
age is strictly
> prohibited. If you have received this communication in error, please
> notify us immediately by email, and delete the original message.
>
--
Ryan Blue
Software Engineer
Netflix
[
https://issues.apache.org/jira/browse/AVRO-1927?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16547243#comment-16547243
]
Ryan Blue commented on AVRO-1927:
-
Sounds like the problem here is actually that there is no validation
[
https://issues.apache.org/jira/browse/AVRO-2164?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16523943#comment-16523943
]
Ryan Blue commented on AVRO-2164:
-
First class types are difficult to add because they break the format's
[
https://issues.apache.org/jira/browse/AVRO-2164?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16411698#comment-16411698
]
Ryan Blue commented on AVRO-2164:
-
The current decimal type is a fixed scale, so you use the same scale
[
https://issues.apache.org/jira/browse/AVRO-2164?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16411615#comment-16411615
]
Ryan Blue commented on AVRO-2164:
-
[~hp9000], I don't follow. How is it lossy? What is "kind of&q
[
https://issues.apache.org/jira/browse/AVRO-2164?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16411572#comment-16411572
]
Ryan Blue commented on AVRO-2164:
-
I disagree that the current format is lossy. The decimal scale is stored
[
https://issues.apache.org/jira/browse/AVRO-1605?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16282158#comment-16282158
]
Ryan Blue commented on AVRO-1605:
-
I don't think Avro should use accessors or friend packages, so I'm -1
[
https://issues.apache.org/jira/browse/AVRO-2021?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16242524#comment-16242524
]
Ryan Blue commented on AVRO-2021:
-
[~nkollar], thanks for pointing out this issue.
I think we should
llár has accepted the PMC's
> > invitation to become a committer on the Apache Avro project.
> >
> > Please join me in congratulating Nándor on this recognition of his great
> > work thus far in our community!
> >
> > -busbey
> >
>
--
Ryan Blue
Software Engineer
Netflix
[
https://issues.apache.org/jira/browse/AVRO-1962?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16240598#comment-16240598
]
Ryan Blue commented on AVRO-1962:
-
There is no UUID logical type in the Avro spec, which means
[
https://issues.apache.org/jira/browse/AVRO-2099?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16219208#comment-16219208
]
Ryan Blue commented on AVRO-2099:
-
I agree, the deserializer shouldn't fail. Decimals with the wrong scale
[
https://issues.apache.org/jira/browse/AVRO-2099?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16217132#comment-16217132
]
Ryan Blue commented on AVRO-2099:
-
With decimals, rounding changes the value. 12.34 is not equal to 12.340
> > }
> >
>
> This has the same problem as one of my earlier suggestions; if you change
> the meaning of the default field, then older readers will read the schema
> with an incorrect default value.
>
> - Bridger Howell
>
> --
>
>
> The information contained in this email message is PRIVATE and intended
> only for the personal and confidential use of the recipient named above. If
> the reader of this message is not the intended recipient or an agent
> responsible for delivering it to the intended recipient, you are hereby
> notified that you have received this message in error and that any review,
> dissemination, distribution or copying of this message is strictly
> prohibited. If you have received this communication in error, please
> notify us immediately by email, and delete the original message.
>
--
Ryan Blue
Software Engineer
Netflix
","maxLength":42}
> {"type":"string","logicalType":"varchar","maxLength":42}
>
> Considering that probably these two SQL engines are the creators of the
> majority of all Avro files written so far, I was wondering whether we
&
ring"
> }
> ]
> }
>
> If changing the "default" property like that has too many issues, I suppose
> a parallel "default-parser" property would do the trick too.
>
> I think this type of approach keeps us neatly separated from logical types,
> s
-readable values in the JSON encoding is even more clearly
> a breaking change. (Although for JSON we could add the human-readable value
> as a separate extra field that gets ignored when reading. Problem is, users
> may be tempted to change the value and be surprised. It's a pity tha
JIRA tickets created in the last 3 months
- 24 JIRA tickets closed/resolved in the last 3 months
--
Ryan Blue
Software Engineer
Netflix
> account linking utility:
> https://gitbox.apache.org/setup/
>
> The git-wip repository will also cease, so folks who currently use it will
> need to update their remote url for existing git clones. We can call this
> out in our contribution docs.
>
--
Ryan Blue
Software Engineer
Netflix
;
> {
> "type": "array",
> "items": { "type": [ "int", "boolean", "string" ] }
> }
>
> According to the spec it is ambiguous:
>
> * items: the schema of the array's items.
>
> I have tried this schema in both python and c and it generates exceptions
> for invalid Schema. I was just curious if this was valid or not.
>
> Thanks
> - John
>
--
Ryan Blue
Software Engineer
Netflix
"Gabor Szadovszky" <ga...@apache.org> wrote:
> >
> > > Hi All,
> > >
> > > It has already appeared in some discussions/code reviews that we might
> > not
> > > want to support hadoop1 anymore. As it would be a breaking change I
> would
[
https://issues.apache.org/jira/browse/AVRO-1672?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16056001#comment-16056001
]
Ryan Blue commented on AVRO-1672:
-
[~DeaconDesperado], contributions are always welcome! Feel free to open
[
https://issues.apache.org/jira/browse/AVRO-2042?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16050899#comment-16050899
]
Ryan Blue commented on AVRO-2042:
-
Here's a pretty good primer on Java's BigDecimal type:
http
then I'm +1 on
> jumping to jdk8. I would prefer not to change the supported jdk
> version(s) for existing minor release lines.
>
> I don't think we should change the Hadoop version.
>
> On Wed, Jun 14, 2017 at 11:23 AM, Ryan Blue <rb...@netflix.com.invalid>
> wr
[
https://issues.apache.org/jira/browse/AVRO-2042?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ryan Blue resolved AVRO-2042.
-
Resolution: Not A Problem
Assignee: Ryan Blue
> Can't reliably write decimal/BigDecimal val
[
https://issues.apache.org/jira/browse/AVRO-2042?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16050746#comment-16050746
]
Ryan Blue commented on AVRO-2042:
-
The problem is that you're converting floats, which causes
o a newer jdk in the next major release 1.9.0?
> > To be more precise:
> > - Upgrading build jdk from 7 to 8?
> > - Upgrading source/target version from 1.6 to 1.7 or 1.8?
> >
> > Thanks a lot,
> > Gabor
> >
>
--
Ryan Blue
Software Engineer
Netflix
.apache.org/confluence/display/AVRO/How+To+Release
>
> S
>
--
Ryan Blue
Software Engineer
Netflix
r Fixed fields. (Zoltan
> > Farkasi via thiru)
> > AVRO-1838: Java: Update checkstyle to catch trailing whitespace.
> > (nielsbasjes via blue)
> >
> >
> > Since several of these are NPE/crashes area I think we should consider
> > getting 1.8.3 out quicker than what we would normally do.
> >
> > --
> > Best regards / Met vriendelijke groeten,
> >
> > Niels Basjes
>
>
>
> --
> busbey
>
--
Ryan Blue
Software Engineer
Netflix
n issue.
> I will be using
> https://repository.apache.org/content/repositories/orgapacheavro-1014 to
> publish.
>
> S
>
> On Wed, May 10, 2017 at 11:38 AM, Ryan Blue <rb...@netflix.com.invalid>
> wrote:
>
> > +1
> >
> > Everything looks good, oth
erify, and test. This vote will remain open for at
> > least
> > > 72 hours. Given sufficient votes, I would like to close it on or about
> > 9AM
> > > CDT on Sunday, 14 May 2017.
> > >
> > > [ ] +1 Release this as Apache Avro 1.8.2
> > > [ ] +0
> > > [ ] -1 Do not release this because...
> > >
> > > --
> > > Suraj Acharya
> >
>
>
>
> --
> Best regards / Met vriendelijke groeten,
>
> Niels Basjes
>
--
Ryan Blue
Software Engineer
Netflix
fixes for Java logical types
> >> * Java: Support for Decimal with specific classes
> >> * Ruby: A fix for compatibility when using snappy
> >> * Python 3: Updated to use the standard module-level logging pattern
> >> * C++: Support for Boost >= 1.59
> >> * And more bug fixes...
> >>
> >> Please download, verify, and test. This vote will remain open for at
> least
> >> 72 hours. Given sufficient votes, I would like to close it on or about
> 9AM
> >> CDT on Sunday, 14 May 2017.
> >>
> >> [ ] +1 Release this as Apache Avro 1.8.2
> >> [ ] +0
> >> [ ] -1 Do not release this because...
> >>
> >> --
> >> Suraj Acharya
> >>
>
>
--
Ryan Blue
Software Engineer
Netflix
s via it.
> >
> > What do folks think about
> >
> > 1) opting in generally
> >
> > 2) using github PRs directly
> >
> > 3) actively encouraging our community to switch to github PRs
> >
> > 4) using github issues
> >
> >
> > [1]: https://gitbox.apache.org/
> >
> > --
> > busbey
> >
>
--
Ryan Blue
Software Engineer
Netflix
[
https://issues.apache.org/jira/browse/AVRO-2023?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15997081#comment-15997081
]
Ryan Blue commented on AVRO-2023:
-
Every release tarball or artifact should have a LICENSE and NOTICE file
[
https://issues.apache.org/jira/browse/AVRO-2023?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15991065#comment-15991065
]
Ryan Blue commented on AVRO-2023:
-
You can add the license files to the RAT excludes. For the JS files
the version number as 0.0.1 for the JS.
> I was wondering what is the opinion of the community on the numbering here.
> I was proposing that we bump that number to 1.7.8 and work from there.
>
> Let me know if you have any concerns with the same.
>
--
Ryan Blue
Software Engineer
Netflix
--
Ryan Blue
in the last 3 months
--
Ryan Blue
> > the integration.
> >
> >
> > If anyone has questions please feel free to ask.
> >
> > Thanks
>
>
>
> --
> busbey
>
--
Ryan Blue
Software Engineer
Netflix
[
https://issues.apache.org/jira/browse/AVRO-1684?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15945493#comment-15945493
]
Ryan Blue commented on AVRO-1684:
-
We should definitely mark 1.8.1 as incompatible. Is it possible to fix
at the
> issue.
> If there are no takers for the same, does anyone have objection if for
> Branch-1.7 the JS component is removed? The builds on Branch-1.8 and higher
> are working fine. There have been changes to the way the npm setup happens
> in Branch-1.8.
>
> Any help is appreciated.
[
https://issues.apache.org/jira/browse/AVRO-1738?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15878844#comment-15878844
]
Ryan Blue commented on AVRO-1738:
-
The content in NOTICE should be in LICENSE as a third-party work
e generated code that is used to set/change the value enforces that
> only the allowed values can be set.
>
> This way a 'reader' can read any value, the schema is compatible in all
> directions.
>
> What do you guys think?
> Is this an idea worth trying out?
>
> --
> Best regards / Met vriendelijke groeten,
>
> Niels Basjes
>
--
Ryan Blue
Software Engineer
Netflix
ers (up 4 in the last 3 months):
- 68 emails sent to list (45 in previous quarter)
## JIRA activity:
- 51 JIRA tickets created in the last 3 months
- 18 JIRA tickets closed/resolved in the last 3 months
--
Ryan Blue
Software Engineer
Netflix
I didn't end up having any time to put together a release candidate this
weekend. Sorry for the delay, we'll have to push for a release in January.
rb
--
Ryan Blue
[
https://issues.apache.org/jira/browse/AVRO-1605?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15725964#comment-15725964
]
Ryan Blue commented on AVRO-1605:
-
I think the second option is the right one. Accessors can be used
[
https://issues.apache.org/jira/browse/AVRO-1605?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15722949#comment-15722949
]
Ryan Blue commented on AVRO-1605:
-
To keep a patch small, we can break it across multiple issues. I'd
[
https://issues.apache.org/jira/browse/AVRO-1885?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15722928#comment-15722928
]
Ryan Blue commented on AVRO-1885:
-
Another that would be nice to get in: AVRO-1957
> Release 1.
Hi everyone,
I'm going to have some time to build 1.8.2 RC2 the 17th and 18th. If you'd
like to get something in, please link it under AVRO-1885 or reply to this
with the issue and we'll try to get it in. Thanks!
rb
On Sun, Dec 4, 2016 at 4:26 PM, Ryan Blue <rb...@netflix.com> wrote:
&g
vro/pull/153
>
> Niels
>
> On 1 Dec 2016 18:31, "Ryan Blue" <rb...@netflix.com.invalid> wrote:
>
> > I'd like to get a release out as well. I'm happy to roll another RC soon.
> >
> > Could someone look at the C# issue that was a problem for some people
the CI stuff (preferable like I
> indicated above).
> My instinct tells me that with that in place any 'build breaking change' in
> 'any language' will be caught very quickly and should not be a problem.
>
> Niels Basjes
>
> P.S. The CI build should do as many of the thing
rds / Met vriendelijke groeten,
>
> Niels Basjes
>
--
Ryan Blue
Software Engineer
Netflix
[
https://issues.apache.org/jira/browse/AVRO-1885?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15712519#comment-15712519
]
Ryan Blue commented on AVRO-1885:
-
I agree, we'll get those in the next RC.
> Release 1.
[
https://issues.apache.org/jira/browse/AVRO-1704?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15712516#comment-15712516
]
Ryan Blue commented on AVRO-1704:
-
You mean erring on the side of caution and using a larger hash? I don't
[
https://issues.apache.org/jira/browse/AVRO-1704?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15712508#comment-15712508
]
Ryan Blue commented on AVRO-1704:
-
With a spec like this, we want to be careful about having too many
[
https://issues.apache.org/jira/browse/AVRO-1957?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15709886#comment-15709886
]
Ryan Blue commented on AVRO-1957:
-
I'll review this for inclusion. Thanks for following up
fferent languages, are they not guaranteed to be
> compatible with each other?
>
> Thanks,
>
> Zoltan
>
> On Sat, Nov 19, 2016 at 10:03 PM Ryan Blue <rb...@netflix.com.invalid>
> wrote:
>
> > This is in response to Tom's concerns:
> >
> >
o make this easier.
rb
On Wed, Nov 16, 2016 at 8:41 PM, Sean Busbey <bus...@cloudera.com> wrote:
> On Tue, Nov 15, 2016 at 3:45 PM, Doug Cutting <cutt...@gmail.com> wrote:
> > On Mon, Nov 14, 2016 at 8:40 PM, Ryan Blue <rb...@netflix.com.invalid>
> wrote:
> >> we do
lf independently. We have a
> viable community combined, but I worry that breaking the project up
> could fragment it into projects that are too tiny to make releases.
> Right now we're all forced to care a bit about other implementations.
>
> Doug
>
> On Sun, Nov 13, 2016 at 12:
changes in Java.
>From my perspective, these two things are a good place to start. To
everyone still reading, what do you think?
rb
--
Ryan Blue
he implementation should be as simple as
>
> @Override
> public Schema getRecommendedSchema() {
> return
> LogicalTypes.timestampMillis().addToSchema(Schema.create(
> Schema.Type.LONG));
> }
>
> If folks agree, I can create a Jira and pull request.
>
> Thanks,
> Sean
>
--
Ryan Blue
Software Engineer
Netflix
;
> When you fix this build problem I vote +1 again.
> Thanks.
>
> Niels
>
> On Thu, Nov 10, 2016 at 5:04 PM, Ryan Blue <rb...@netflix.com.invalid>
> wrote:
>
> > The C# issue was fixed by AVRO-1626 [1], which had to be reverted for the
> > 1.8.2 RC because it
e tests run. But removing it makes the
> tests
> >> fail on my system (CentOS 7). This suggests that something is missing
> from
> >> the docker setup and is being picked up from the host computer, but I
> >> haven't had a chance to investigate.
> >>
> >&
[
https://issues.apache.org/jira/browse/AVRO-1950?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15644670#comment-15644670
]
Ryan Blue commented on AVRO-1950:
-
I think String is the right encoding for Decimal in JSON. Otherwise
to avro. PFA my sample
> files, please help me out as to how can I achieve this.
> >
> >
> > Exception in thread "main" org.apache.avro.AvroTypeException: Expected
> start-union. Got VALUE_STRING
> >
> >
> >
> >
> >
> > Thank you,
> > Anand
> >
>
>
--
Ryan Blue
Software Engineer
Netflix
[
https://issues.apache.org/jira/browse/AVRO-1856?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ryan Blue updated AVRO-1856:
Fix Version/s: (was: 1.8.2)
> Update ConcatTool to support appending to an input file inst
+1
Verified signatures, checksums. Ran build.sh test in docker and all tests
are passing.
rb
On Sun, Nov 6, 2016 at 1:59 PM, Ryan Blue <b...@apache.org> wrote:
> Hi everyone,
>
> I propose the following RC to be released as official Apache Avro 1.8.2
> release.
use...
--
Ryan Blue
[
https://issues.apache.org/jira/browse/AVRO-1950?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15642430#comment-15642430
]
Ryan Blue commented on AVRO-1950:
-
I've been thinking about this and I think maybe what we should do
[
https://issues.apache.org/jira/browse/AVRO-1626?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ryan Blue updated AVRO-1626:
Fix Version/s: (was: 1.8.2)
1.9.0
> Missing lang/csharp/src/apache/perf/app.con
[
https://issues.apache.org/jira/browse/AVRO-1626?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ryan Blue reopened AVRO-1626:
-
This patch caused the 1.8.2 tests to fail in docker. I'm pushing it out of the
1.8.2 release, we can fix
[
https://issues.apache.org/jira/browse/AVRO-1951?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ryan Blue resolved AVRO-1951.
-
Resolution: Fixed
> Python tests fail because dummyserver.net no longer exi
Ryan Blue created AVRO-1951:
---
Summary: Python tests fail because dummyserver.net no longer
exists.
Key: AVRO-1951
URL: https://issues.apache.org/jira/browse/AVRO-1951
Project: Avro
Issue Type
[
https://issues.apache.org/jira/browse/AVRO-1897?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ryan Blue updated AVRO-1897:
Resolution: Fixed
Status: Resolved (was: Patch Available)
Merged. Thanks for fixing
[
https://issues.apache.org/jira/browse/AVRO-1907?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ryan Blue updated AVRO-1907:
Resolution: Fixed
Fix Version/s: 1.8.2
Status: Resolved (was: Patch Available)
Merged
[
https://issues.apache.org/jira/browse/AVRO-1626?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15640463#comment-15640463
]
Ryan Blue commented on AVRO-1626:
-
Merged the fix from Naruto. I don't see a JIRA account, so I'm leaving
[
https://issues.apache.org/jira/browse/AVRO-1626?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ryan Blue resolved AVRO-1626.
-
Resolution: Fixed
Fix Version/s: 1.8.2
> Missing lang/csharp/src/apache/perf/app.con
[
https://issues.apache.org/jira/browse/AVRO-1882?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ryan Blue updated AVRO-1882:
Assignee: Sachin Goyal
> ConcurrentHashMap with non-string keys fails in Java
nks
> SG
>
> On Sun, Oct 30, 2016 at 1:46 PM, Ryan Blue <b...@apache.org> wrote:
>
> > Hi everyone,
> >
> > I'm going to try to get a 1.8.2 release candidate out this week. There's
> > only one issue that I think is a blocker on AVRO-1885, and I think we
someone familiar with the C++ implementation take the time to review
them?
rb
--
Ryan Blue
can discuss
on that issue.
Thanks!
rb
--
Ryan Blue
[
https://issues.apache.org/jira/browse/AVRO-1605?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15620519#comment-15620519
]
Ryan Blue commented on AVRO-1605:
-
This is looking better, but I'd like to see more justification
[
https://issues.apache.org/jira/browse/AVRO-1945?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15620467#comment-15620467
]
Ryan Blue commented on AVRO-1945:
-
Your problem has to do with how values are represented. It isn't
[
https://issues.apache.org/jira/browse/AVRO-1945?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ryan Blue resolved AVRO-1945.
-
Resolution: Not A Bug
> Python float deviation
> --
>
> Ke
1 - 100 of 766 matches
Mail list logo
