Re: [DISCUSS] CEP-36: A Configurable ChannelProxy to alias external storage locations

Right, exactly. Which (I think) makes the object store about as valuable as an ephemeral disk if you don't keep everything on there. It's a tradeoff I'd never use given the cost / benefit. Does that mean you agree that we should focus on writethrough cache mode first? Jon On Fri, Apr 11, 202

Re: [DISCUSS] CEP-36: A Configurable ChannelProxy to alias external storage locations

> On Apr 11, 2025, at 1:15 PM, Jon Haddad wrote: > > > I also keep running up against my concern about treating object store as a > write back cache instead of write through. "Tiering" data off has real > consequences for the user, the big one being data loss, especially with > regards to

Re: [DISCUSS] CEP-36: A Configurable ChannelProxy to alias external storage locations

I've been thinking about this a bit more recently, and I think Joey's suggestion about improving the yaml based disk configuration is a better first step than what I wrote (table definition), for a couple reasons. 1. Attaching it to the schema means we need to have the disk configuration as part o

Re: Project hygiene on old PRs

I have a small script which scans GH pull requests (their titles) and looks into JIRA to see what is their status. When it is "resolved" it prints it to the console. Then I go over the links of PRs and close them one by one. This relies on the title of the PR to be in exact format (CASSANDRA-123 a

Re: Constraint's "not null" alignment with transactions and their simplification

Fair question. I think the only reason to favor JSON over anything else is it's popularity. I think if a JSON type is simply a text type with validation, then adding a simple validator for other formats is probably easy. We've already got YAML support in the codebase so adding yaml would be triv

Re: Constraint's "not null" alignment with transactions and their simplification

Jon, that dedicated JSON type, I was thinking about this literally yesterday. I like the idea. There would be an implicit check on its value with json constraint under the hood. But that also got me thinking "why just JSON"? As if it was the only format out there ... Probably very widely used and

Re: Constraint's "not null" alignment with transactions and their simplification

We can think about this. I don't mind supporting both. It needs a little bit more love in parser I guess. Most probably doable, as syntactic sugar. On Fri, Apr 11, 2025 at 6:25 PM Jon Haddad wrote: > I agree NOT NULL is nicer than check not null. > > Taking the JSON bit a step further, a dedicat

Re: Constraint's "not null" alignment with transactions and their simplification

_If we aren’t matching the feature, why are we matching the keyword?_ ??? Nobody said that if we do not use the exact same feature we have to rename it. On Fri, Apr 11, 2025 at 6:13 PM Benedict wrote: > [image: elephant.png] > > 5.5. Constraints >

Re: Constraint's "not null" alignment with transactions and their simplification

I agree NOT NULL is nicer than check not null. Taking the JSON bit a step further, a dedicated JSON type is better than a check, but that's probably out of scope. For inspiration, I've worked with Postgre's JSONB type in the past, and it was awesome. https://www.postgresql.org/docs/current/funct

Re: Constraint's "not null" alignment with transactions and their simplification

5.5. Constraintspostgresql.orgSee the note directly above section 5.5.2 - Postgres supports functions in the CHECK predicate and requires they are pure functions (ie always yield the same result).The point is, CHECK is consistently a predicate defined over a field _expression_. If we aren’t matchin

Re: [DISCUSS] 5.1 should be 6.0

+1 to 6.0 And David makes a good point about making sure that we support 4.x to 6.0 upgrades. Thanks, Aaron On Fri, Apr 11, 2025 at 1:03 AM guo Maxwell wrote: > +1 to 6.0 > > Berenguer Blasi 于2025年4月11日周五 13:53写道： > >> +1 6.0 >> On 10/4/25 23:57, David Capwell wrote: >> >> +1 to 6.0 >> Stron

Re: Constraint's "not null" alignment with transactions and their simplification

I went through Postgres' docs in a quite elaborate manner and I do not see any usage of "constraint functions" as we have them. Both MySQL and Postgres seem to only provide simple predicates (using relational operators) and "functions" as we have them (e.g. json / length) are not supported. So in t

Re: [DISCUSS] How we version our releases

+1. It's the proper signal to the community. A .1 release could still be done as an exception, but I have a hard time thinking of a case other than supporting a newer JDK without any other changes. On Fri, Apr 11, 2025 at 7:19 AM Jeremiah Jordan wrote: > +1 from me. > No more wondering what th

Re: Constraint's "not null" alignment with transactions and their simplification

Benedict: An alternative for that, keeping the CHECK word, would be to change the constraint name to IS_JSON. CHECK IS_JSON would read as you intend without the need to jump to REQUIRE. I think that’s true for the rest of provided constraints as well. Bernardo > On Apr 11, 2025, at 6:02 AM,

Re: Constraint's "not null" alignment with transactions and their simplification

Sure, and I won’t push hard on this but I’m not sure why we would copy without actually copying.For comparison, oracle and sql server also have the CHECK keyword for predicates involving the column, but permit other constraints, eg NOT NULL or UNIQUE without first writing CHECK.So, to me, CHECK is

Re: [DISCUSS] 5.1 should be 6.0

> David makes a good point about making sure that we support 4.x to 6.0 > upgrades. Supporting live upgrades from every GA supported version today seems obvious as a lazy consensus to me. Given how confusing our release versioning has been it's wort

Re: [DISCUSS] How we version our releases

> So we avoid 6.1, 7.2, etc? Does this imply that each release is allowed to > make breaking changes (assuming they followed the “correct” deprecation > process)? Yes and no. A release can't make a breaking change *relative to the immediately preceding release*, if something has been deprecat

Re: Project hygiene on old PRs

+1 from me. My intuition is that this is a logical consequence of us not using github to merge PR's so they don't auto-close. Which seems like it's a logical consequence of us using merge commits instead of per-branch commits of patches. The band-aid of at least having a human-in-the-loop to cl

Re: [DISCUSS] How we version our releases

+1 from me. No more wondering what the next version number will be. No more wondering what version I can upgrade from to use the new release. -Jeremiah On Apr 10, 2025 at 3:54:13 PM, Josh McKenzie wrote: > This came up in the thread from Jon on "5.1 should be 6.0". > > I think it's important t

Re: Constraint's "not null" alignment with transactions and their simplification

We have taken a different approach though, as we do not actually take a predicate on the RHS and do not supply the column name. In our examples we had eg CHECK JSON, which doesn’t parse unambiguously to a human. The equivalent to Postgres would seem to be CHECK is_json(field).I’m all for following

Re: Constraint's "not null" alignment with transactions and their simplification

While modelling that, we followed how it is done in SQL world, PostgreSQL as well as MySQL both use CHECK. https://www.postgresql.org/docs/current/ddl-constraints.html#DDL-CONSTRAINTS-CHECK-CONSTRAINTS https://dev.mysql.com/doc/refman/8.4/en/create-table-check-constraints.html On Fri, Apr 11, 202

Re: Constraint's "not null" alignment with transactions and their simplification

I would prefer require/expect/is over checkOn 11 Apr 2025, at 08:05, Štefan Miklošovič wrote:Yes, you will have it like that :) Thank you for this idea. Great example of cooperation over diverse domains.On Fri, Apr 11, 2025 at 12:29 AM David Capwell wrote:I am biased but I do

Re: [DISCUSS] How we version our releases

I proposed dropping Minor versions a few years ago so I’m cool with this, but regarding policies I do think we’d be better off just creating a version compatibility matrix and quit agonising over it. With N policies across N releases I’m not sure they’re providing much certainty to users. We really

Re: [DISCUSS] How we version our releases

On Thu, 10 Apr 2025 at 22:54, Josh McKenzie wrote: > … > So here's what I'm thinking: a new release strategy that doesn't use > .MINOR of semver. Goals: > - Simplify versioning for end users > - Provide clearer contracts for users as to what they can expect in > releases > - Simplify support for

Re: Constraint's "not null" alignment with transactions and their simplification

Yes, you will have it like that :) Thank you for this idea. Great example of cooperation over diverse domains. On Fri, Apr 11, 2025 at 12:29 AM David Capwell wrote: > I am biased but I do prefer > > val3 text CHECK NOT NULL AND JSON AND LENGTH() < 1024 > > Here is a similar accord CQL > > BEGIN