Accepting this pull request as-is will break backwards compatibility. I think if the new behavior is desired, it should be based on some configuration.
On Mon, Feb 27, 2017 at 11:40 AM Bruce Schuchardt <bschucha...@pivotal.io> wrote: > I think in this case it would be replacing the messages used to > replicate changes with ones that send the operation + parameters instead > of the modified entry's new value. That could be done by creating a new > subclass of BucketRegion. Stick the operation+params into the > EntryEventImpl that follows the operation through the system and in the > BucketRegion subclass pull out that data and send it instead of the > event's newValue. > > Le 2/27/2017 à 11:13 AM, Real Wes a écrit : > > I'm not following what a "simple operation replication framework" is and > how it applies to the Redis API. If you replicate operations, you still > need to update the data at some point, causing a synchronous replication > event so as to provide HA. What is, in more detail, a "simple operation > replication framework"? > > > > Regards, > > Wes Williams > > Sent from mobile phone > > > >> On Feb 27, 2017, at 2:07 PM, Bruce Schuchardt <bschucha...@pivotal.io> > wrote: > >> > >> What I like about using the existing delta-prop mechanism is it will > also extend to client subscriptions & WAN. It would take a lot of work to > propagate Redis commands through those paths. > >> > >>> Le 2/27/2017 à 10:35 AM, Hitesh Khamesra a écrit : > >>> The simplicity of Redis API making this problem (delta update)most > apparent. But, I would imagine many Geode apps has a similar use case. > >>> > >>> -Hitesh > >>> > >>> From: Michael Stolz <mst...@pivotal.io> > >>> To: dev@geode.apache.org > >>> Sent: Monday, February 27, 2017 9:06 AM > >>> Subject: Re: [DISCUSS] changes to Redis implementation > >>> It does seem like the operations will often be much smaller than > the data > >>> they are operating on. > >>> It is almost the classic "move the code to the data" pattern. > >>> > >>> -- > >>> Mike Stolz > >>> Principal Engineer, GemFire Product Manager > >>> Mobile: +1-631-835-4771 <(631)%20835-4771> > >>> > >>> On Mon, Feb 27, 2017 at 10:51 AM, Udo Kohlmeyer <ukohlme...@pivotal.io > > > >>> wrote: > >>> > >>>> Delta could provide us a mechanism to replicate only what is required. > >>>> > >>>> I wonder if we could not create a simple operation replication > framework. > >>>> Rather than writing a potential large amounts of code for delta, we > >>>> replicate only the operation. > >>>> > >>>> > >>>>> On 2/27/17 07:18, Wes Williams wrote: > >>>>> > >>>>> Replicating a whole collection because of 1 change does not really > make > >>>>>> too much sense.<< > >>>>> I agree but won't delta replication prevent sending the entire > collection > >>>>> across the wire? > >>>>> > >>>>> *Wes Williams | Pivotal Advisory **Data Engineer* > >>>>> 781.606.0325 <(781)%20606-0325> > >>>>> http://pivotal.io/big-data/pivotal-gemfire > >>>>> > >>>>> On Mon, Feb 27, 2017 at 10:08 AM, Udo Kohlmeyer < > ukohlme...@pivotal.io> > >>>>> wrote: > >>>>> > >>>>> I've quickly gone through the changes for the pull request. > >>>>>> The most significant change of this pull request is that the > collections > >>>>>> that initially were regions are single collections (not > distributed). > >>>>>> That > >>>>>> said, this is something that we've been discussing. The one thing > that I > >>>>>> wonder about is, what will the performance look like when the > collections > >>>>>> become really large? Replicating a whole collection because of 1 > change > >>>>>> does not really make too much sense. > >>>>>> > >>>>>> Maybe this implementation becomes the catalyst for future > improvements. > >>>>>> > >>>>>> --Udo > >>>>>> > >>>>>> > >>>>>> > >>>>>> On 2/24/17 15:25, Bruce Schuchardt wrote: > >>>>>> > >>>>>> Gregory Green has posted a pull request that warrants discussion. It > >>>>>>> improves performance for Sets and Hashes by altering the storage > format > >>>>>>> for > >>>>>>> these collections. As such it will not permit a rolling upgrade, > though > >>>>>>> the Redis adapter is labelled "experimental" so maybe that's okay. > >>>>>>> > >>>>>>> https://github.com/apache/geode/pull/404 > >>>>>>> > >>>>>>> The PR also fixes GEODE-2469, inability to handle hash keys having > >>>>>>> colons. > >>>>>>> > >>>>>>> There was some discussion about altering the storage format that > was > >>>>>>> initiated by Hitesh. Personally I think Gregory's changes are > better > >>>>>>> than > >>>>>>> the current implementation and we should accept them, though I > haven't > >>>>>>> gone > >>>>>>> through the code changes extensively. > >>>>>>> > >>>>>>> > >>>>>>> > >>> > >
