To wrap things up - I'm considering this proposal as having failed; so I've
marked the 3 associated RBs as discarded.
I'll be working on https://issues.apache.org/jira/browse/THRIFT-3583 to
introduce an immutable builder-style of java codegen that carries over
thrift annotations to Apache Thrift.
On Thu, Jan 28, 2016 at 8:26 AM, John Sirois wrote:
> On Thu, Jan 28, 2016 at 6:45 AM, Jake Farrell wrote:
>
> > +1 to making this apart of Thrift, i'm happy to help shepard this on the
> > Thrift side and get it in as soon as its ready
> >
>
> I've filed https://issues.apache.org/jira/browse/TH
On Thu, Jan 28, 2016 at 6:45 AM, Jake Farrell wrote:
> +1 to making this apart of Thrift, i'm happy to help shepard this on the
> Thrift side and get it in as soon as its ready
>
I've filed https://issues.apache.org/jira/browse/THRIFT-3583 to use as the
basis for discussion of this feature over
+1 to making this apart of Thrift, i'm happy to help shepard this on the
Thrift side and get it in as soon as its ready
-Jake
On Wed, Jan 27, 2016 at 8:08 PM, Maxim Khutornenko wrote:
> I am +1 to making immutable thrift objects solely based on perf numbers.
>
> My biggest concern though is mai
--
John Sirois
303-512-3301
On Jan 27, 2016 6:08 PM, "Maxim Khutornenko" wrote:
>
> I am +1 to making immutable thrift objects solely based on perf numbers.
>
> My biggest concern though is maintenance of a pretty intricate codebase,
> especially when it comes to upgrading any of the frameworks in
I am +1 to making immutable thrift objects solely based on perf numbers.
My biggest concern though is maintenance of a pretty intricate codebase,
especially when it comes to upgrading any of the frameworks involved.
Bill's suggestion to explore paths to make this a part of Apache Thrift
sounds gre
Tony - this would not be a technical fork so much as a spiritual fork.
While we would have our own bugs to work out, the only upstream exposure
would be IDL or wire format changes.
On Wed, Jan 27, 2016 at 4:58 PM, Tony Dong
wrote:
> Awesome performance numbers! I don't particularly know the logi
Awesome performance numbers! I don't particularly know the logistics of
upstreaming a change like this, but optimistically I would suggest
upstreaming it to Apache Thrift if possible.
As someone that maintains a fork of a thrift compiler(fork of scrooge), I
have to say that it's not that fun. Ther
Firstly - thanks for the clean organization and delineation of steps in
this change. Top notch work!
Some of the performance improvements are very nice; and in a particularly
hot code path. I will wager a guess that the majority of the savings is in
avoiding what amounts to copy constructors bet
Some high level comments without looking at the code.
I'm in favor from abandoning the thrift generated java code in favor of
immutable objects. I think it is easier to reason about and will ensure we
have less errors in our code. If I understand correctly, the ProtoBuf
format does this by default
On Tue, Jan 26, 2016 at 8:47 PM, John Sirois wrote:
> Context: Aurora uses the official Apache Thrift compiler today plus a
> home-grown python code generator [1] for immutable "entity" (I*) wrappers.
>
> The proposal is to switch from using the Apache Thrift code generator to a
> home grown gene
Context: Aurora uses the official Apache Thrift compiler today plus a
home-grown python code generator [1] for immutable "entity" (I*) wrappers.
The proposal is to switch from using the Apache Thrift code generator to a
home grown generator. The proposal comes with a concrete example in the
form
12 matches
Mail list logo
