[Spring CI] Spring Data GemFire > Nightly-ApacheGeode > #1065 was SUCCESSFUL (with 2456 tests)

2018-10-09 Thread Spring CI
--- Spring Data GemFire > Nightly-ApacheGeode > #1065 was successful. --- Scheduled 2458 tests in total. https://build.spring.io/browse/SGF-NAG-1065/ -- Thi

Re: PuAll vs List

2018-10-09 Thread Jason Huynh
I think this question is too abstract to have a great answer and also depends on if you want the processing to occur on the client or server or whether your client can hold entire lists of values... The downside to option 1 is that you will need to retrieve the entire list of objects, depending on

Re: Queries on key fields

2018-10-09 Thread Jason Huynh
Pdx and indexing are different altogether. Pdx affects the serialization of the object. Indexing affects querying speed. Together, they should improve the entire query speed because querying can cause deserializations. With Pdx it should speed up look ups by not causing full deserialization per

Re: Queries on key fields

2018-10-09 Thread anjana_nair
is there an advantage of using one vs other index on a field vs PDX serialization as both are used in query execution. -- Sent from: http://apache-geode-incubating-developers-forum.70738.x6.nabble.com/

Store objects as List vs running queries and PutAll

2018-10-09 Thread anjana_nair
I have a question regaring the performance metrics of putAll vs storing objects directly as List. which would be more performant 1. store object of the form { key1, {sessionId, List}} 2. store each message object in a list with unique key {key, sessionid, data} and then use putall for st

PuAll vs List

2018-10-09 Thread anjana_nair
1.which is more performant - aggregating on client side and storing objects as a list and retrieving the whole object as an a list or 2. storing objects using putAll and running queries to get the objects. -- Sent from: http://apache-geode-incubating-developers-forum.70738.x6.nabble.com/

Re: [VOTE] Time-based release schedule for minor releases

2018-10-09 Thread Alexander Murmann
Bruce, agreed. I think we should eliminate all the fluff language around "significant improvements". What's "significant" is entirely subjective. I'd prefer to stick to the much simpler definition from semver.org: > > Given a version number MAJOR.MINOR.PATCH, increment the: > >1. MAJOR version

Re: [VOTE] Time-based release schedule for minor releases

2018-10-09 Thread Bruce Schuchardt
-1 To me the definition of major vs minor releases is too muddy.  Our Versioning and Branching page has requirements for a Minor release that seem orthogonal to this discussion.  A Minor release "must definitely incl

Re: [VOTE] Time-based release schedule for minor releases

2018-10-09 Thread Kenneth Howe
+1 for 3-month minor release schedule > On Oct 9, 2018, at 12:32 AM, Juan José Ramos wrote: > > +1 for time-based releases. > > On Tue, Oct 9, 2018 at 12:02 AM Michael Stolz wrote: > >> +1 Quarterly releases >> >> -- >> Mike Stolz >> Principal Engineer - Gemfire Product Manager >> Mobile: 63

Re: [VOTE] Time-based release schedule for minor releases

2018-10-09 Thread Juan José Ramos
+1 for time-based releases. On Tue, Oct 9, 2018 at 12:02 AM Michael Stolz wrote: > +1 Quarterly releases > > -- > Mike Stolz > Principal Engineer - Gemfire Product Manager > Mobile: 631-835-4771 > > On Oct 8, 2018 6:52 PM, "Sai Boorlagadda" > wrote: > > > +1 for time-based minors (if patches ar