Hi All,
Looking for feedback on the proposal to [un/de]deprecate the IndexType ENUM
on Geode.
https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=135863477
Thanks, Joris.
--
*Joris Melchior *
CF Engineering
Pivotal Toronto
416 877 5427
“Programs must be written for people to read
> On Dec 1, 2019, at 2:40 PM, John Blum wrote:
>
> After some modifications to Spring Data for Apache Geode (Spring Data
> Geode; SDG), I was finally able to build SDG with Apache Geode 1.11.
>
> While I support the modularization effort, I would make it very clear (in
> documentation) now th
Just as a reminder we do have a light weight process for handling changes
in "public" areas like configuration, monitoring, command line tools, etc.
So as we get close to proposing changing something for the better we might
want to make sure we are following the process to ensure we are doing the
r
+1
On 12/2/19 1:29 AM, Mario Kevo wrote:
Hi,
There is another potential functionality we would like to discuss and get some
comments for. The idea is TLS certificate based authorization. Currently, if a
user wants secure communication (TLS) + authorization, he needs to enable TLS
and acces
+1
On Mon, Dec 2, 2019 at 12:26 PM Jacob Barrett wrote:
> +1
>
> > On Dec 2, 2019, at 6:47 AM, Jens Deppe wrote:
> >
> > Hi Mario,
> >
> > Definitely sounds like a good idea! Feel free to write up a RFC proposal
> > with more details.
> >
> > Thanks
> > --Jens
> >
> > On Mon, Dec 2, 2019 at 1:3
Okay, that is good feedback. I lean towards un-deprecating as well. Let me
write a draft proposal for some changes so everyone can chime in and
hopefully we'll have a workable target at the end of it.
Thanks, Joris.
On Mon, Dec 2, 2019 at 1:00 PM John Blum wrote:
> My vote would be to UNDEPRECA
My vote would be to UNDEPRECATE the IndexType in Apache Geode. There are
several codepaths in SDG that use the IndexType to make certain decisions.
I also think having an Enum is much more flexible than having a method per
Index type, particularly since you can use Enum values in switch
statement
Hi Joris,
Just some guesses and no actual answer from me here:
The deprecation of the index type was before HASH indexes were created, and
my guess was due to the introduction of the "new at the time" query service
apis (the javadoc:@deprecated As of 6.6.1. Check {@link QueryService} for
changes.
Hi Mario,
Sorry I reread the original email and see that the exception points to a
different problem.. I think your fix addresses an old version seeing an
unknown new lucene format, which looks good. The following exception looks
like it's the new lucene library not being able to read the older f
+1
> On Dec 2, 2019, at 6:47 AM, Jens Deppe wrote:
>
> Hi Mario,
>
> Definitely sounds like a good idea! Feel free to write up a RFC proposal
> with more details.
>
> Thanks
> --Jens
>
> On Mon, Dec 2, 2019 at 1:30 AM Mario Kevo wrote:
>
>> Hi,
>>
>>
>>
>> There is another potential func
Hi Jason,
At this point it is not about creating but returning the Region with an
indicator in the management API without using deprecated parts. Under the
covers the QueryService java api still uses the IndexType ENUM and had
assumed that an alternative would be provided when something is marked
Hi Joris,
How are you creating the index? If using the QueryService java api, there
should be createKeyIndex() and createIndex() methods. These methods should
create the primary key index and the functional index.
I am not sure if there is an alternative in gfsh... it might still be using
the I
Thanks for the positive feedback. This proposal is accepted and development
will proceed.
--Jens
On Mon, Nov 25, 2019 at 9:27 AM Dale Emery wrote:
> +𝞹
> —
> Dale Emery
> dem...@pivotal.io
>
>
>
> > On Nov 22, 2019, at 8:39 AM, Jens Deppe wrote:
> >
> > Hello All,
> >
> > We'd like to propose
For the purpose of moving this forward, I have merged PR #4311 [1]. From a
runtime POV this now requires a minimum 3.0 servlet compatible container.
Documented minimum, however, is at least 3.1.
I suggest that if anyone would like to see documented newer support that
that should be proposed separa
Hi Mario,
Definitely sounds like a good idea! Feel free to write up a RFC proposal
with more details.
Thanks
--Jens
On Mon, Dec 2, 2019 at 1:30 AM Mario Kevo wrote:
> Hi,
>
>
>
> There is another potential functionality we would like to discuss and get
> some comments for. The idea is TLS cert
I started with implementation of Option-1.
As I understood the idea is to block all puts(put them in the queue) until all
members are upgraded. After that it will process all queued events.
I tried with Dan's proposal to check on start of LuceneEventListener.process()
if all members are upgrade
Hi,
There is another potential functionality we would like to discuss and get some
comments for. The idea is TLS certificate based authorization. Currently, if a
user wants secure communication (TLS) + authorization, he needs to enable TLS
and access control. The user also needs to handle bot
17 matches
Mail list logo