Re: Tokenization and SAI query syntax

Yep, this sounds like the potentially least bad approach for now. Sorry Caleb, I jumped in without properly reading the thread and assumed we were proposing changes to CQL.If it’s clear we’re dropping into a sub-language and providing a sub-query to it that’s SAI-specific, that gives us pretty broa

Re: Tokenization and SAI query syntax

Been chatting a bit w/Caleb about this offline and poking around to better educate myself. > using functions (ignoring the implementation complexity) at least removes > ambiguity. This, plus using functions lets us kick the can down the road a bit in terms of landing on an integrated grammar w

Re: Tokenization and SAI query syntax

> I do not think we should start using lucene syntax for it, it will make people think they can do everything else lucene allows. I'm sure we won't be supporting everything Lucene allows, but this is going to evolve. Right off the bat, if you introduce support for tokenization and filtering, someo

Re: Tokenization and SAI query syntax

Why not start with SQLish operators supported by many databases (LIKE and CONTAINS)? On Mon, Aug 7, 2023 at 10:01 PM J. D. Jordan wrote: > I am also -1 on directly exposing lucene like syntax here. Besides being > ugly, SAI is not lucene, I do not think we should start using lucene syntax > for

Re: August 5.0 Freeze (with waivers…) and a 5.0-alpha1

Merge path for bugs on 3.0 is pretty brutal at this point. Good thing 2 will drop off when we GA 5.0. Updated wiki w/new branches plus some examples: link On Mon, Aug 7, 2023, at 11:18 AM, Mick Se

Re: Tokenization and SAI query syntax

I am also -1 on directly exposing lucene like syntax here. Besides being ugly, SAI is not lucene, I do not think we should start using lucene syntax for it, it will make people think they can do everything else lucene allows.On Aug 7, 2023, at 5:13 AM, Benedict wrote:I’m strongly opposed to : It

Re: Tokenization and SAI query syntax

@Benedict I'm not particularly keen to try to graft the Lucene syntax into CQL itself, to be clear. What I'm proposing is more along the lines of allowing that syntax via "expr" and leaving that Lucene systems would call "filters" in predicates currently expressible by CQL. On Mon, Aug 7, 2023 at

Re: August 5.0 Freeze (with waivers…) and a 5.0-alpha1

Forward merging cassandra-4.1 … cassandra-5.0 … trunk is now required ! trunk is still got 5.0 in the build.xml, but that's only temporary until 18705 lands, and of no harm i believe… (i could easily be wrong, but not AFAIK) On Mon, 7 Aug 2023 at 13:38, Brandon Williams wrote: > Is this intend

Re: August 5.0 Freeze (with waivers…) and a 5.0-alpha1

Is this intended to be used now and change the merge order? I ask because 18705 mentions bumping build.xml and CHANGES.txt amongst others that haven't been done which is leading to confusion. Kind Regards, Brandon On Sat, Aug 5, 2023 at 4:46 PM Mick Semb Wever wrote: > > > With no objections, a

Re: Tokenization and SAI query syntax

I’m strongly opposed to : It is very dissimilar to our current operators. CQL is already not the prettiest language, but let’s not make it a total mish mash.On 7 Aug 2023, at 10:59, Mike Adamson wrote:I am also in agreement with 'column : token' in that 'I don't hate it' but I'd like to offer an

Re: Tokenization and SAI query syntax

I am also in agreement with 'column : token' in that 'I don't hate it' but I'd like to offer an alternative to this in 'column HAS token'. HAS is currently not a keyword that we use so wouldn't cause any brain conflicts. While I don't hate ':' I have a particular dislike of the lucene search synta

Re: Removal of commitlog_sync_batch_window_in_ms in 5.0

Since there is no response / nobody seems to see this as an issue, I am going to remove it (will be removed in 5.0). From: Miklosovic, Stefan Sent: Wednesday, August 2, 2023 21:57 To: dev@cassandra.apache.org Subject: Removal of commitlog_sync_batch_window