> I expect that a lot of use cases will update M and insert into N tables based
> on one condition
Jeff, the issue is a scope issue
— works fine today
IF …
UPDATE ….;
INSERT …;
END IF
— also works today just fine; no condition is used with the mutations
UPDATE ….;
INSERT …;
— does not wor
Not quite sure I follow, but the syntax we agreed permits you to update as many
tables as you like with a single condition, or with no condition, but not to
mix both conditional and unconditional updates in a single transaction.
My preference is to keep this simple until we permit arbitrarily co
I expect that a lot of use cases will update M and insert into N tables
based on one condition, so if that's a problem with the grammar today, I
think it'd probably be worth the time to sort that out?
On Wed, Sep 21, 2022 at 12:42 PM David Capwell wrote:
> Caleb is making great progress on thi
My inclination is not to support this until we support arbitrary numbers of IF
statements. It’s one too many arbitrary restrictions and it potentially gets
confusing.
But I don’t feel super strongly about it.
> On 21 Sep 2022, at 20:56, Patrick McFadin wrote:
>
>
> I'm also working on diffe
+1
Od: Andrés de la Peña
Odoslané: pondelok 19. septembra 2022 13:39
Komu: dev@cassandra.apache.org
Predmet: [VOTE] CEP-20: Dynamic Data Masking
NetApp Security WARNING: This is an external email. Do not click links or open
attachments unless you recognize the s
I'm also working on different use cases and syntax for Accord :D
I'm +1 on this change and leaving the door open for maybe a few more as we
test this out. It needs to be functionally useful for developers in v1, and
I think it's worth the changes to get it right.
One other thing Caleb and I have
Caleb is making great progress on this, and I have been working on CQL fuzz
testing the new grammar to make sure we flesh out cases quickly; one thing we
hit was about mixing conditional and non-conditional updates; will use a
example to better show
BEGIN TRANSACTION
LET a = (SELECT * FROM ….
Agrona looks like it has quite a bit more than just buffers, so if we add
this as a dependency for the new memtable, would it potentially open up use
of other parts of Agrona (wittingly or not)? Unless I misunderstood, wasn't
part of the new memtable implementation an interface to allow this to be
+1 to David and Benedict's sentiments here. Probably a good habit for us to get
into in general (including the "why" when hitting up ML about a new dep)
On Wed, Sep 21, 2022, at 1:29 PM, David Capwell wrote:
> I am +1 to adding, good library, but agree with Benedict it would be good to
> know “w
I am +1 to adding, good library, but agree with Benedict it would be good to
know “why”.
> On Sep 21, 2022, at 5:40 AM, Benedict wrote:
>
> In principle no, it’s a high quality library. But it might help to briefly
> outline what it’s used for. I assume it is instead of ByteBuffer? In which
>
In principle no, it’s a high quality library. But it might help to briefly
outline what it’s used for. I assume it is instead of ByteBuffer? In which case
it could maybe be worthwhile discussing as a project how we foresee interaction
with existing buffer machinery, and maybe how we expect our b
+1
On Wed, Sep 21, 2022, 7:28 AM Branimir Lambov wrote:
> Hi everyone,
>
> CASSANDRA-17240 (Trie memtable implementation) introduces a dependency on
> the agrona library (https://github.com/real-logic/agrona).
>
> Does anyone have any objections to adding this dependency?
>
> Regards,
> Branimi
Almost added it twice myself. High quality library with many nifty classes, +1
from me.
> On 21 Sep 2022, at 13:28, Branimir Lambov wrote:
>
> Hi everyone,
>
> CASSANDRA-17240 (Trie memtable implementation) introduces a dependency on the
> agrona library (https://github.com/real-logic/agrona
Hi everyone,
CASSANDRA-17240 (Trie memtable implementation) introduces a dependency on
the agrona library (https://github.com/real-logic/agrona).
Does anyone have any objections to adding this dependency?
Regards,
Branimir
Hello Amit,
This paper may be of interest to you:
https://www.vldb.org/pvldb/vol15/p3359-lambov.pdf
We did a range of tests that are similar to your scenario and realized
several things early on:
- Memory-mapping the commit log in combination with memory-mapped data
or index files causes l
15 matches
Mail list logo
