;>>> assumptions about that today, as historically these sorts of
> intentions
> >>>> haven’t lasted.
> >>>>
> >>>> I’m fairly against the idea of introducing hard restrictions on this,
> >> and
> >>>> potentially os
t 12:13 PM, bened...@apache.org wrote:
>>>>>
>>>>> I agree that we don’t need to block the CEP on this, and that we should
>>>> have that discussion. But it’s worth noting that the CEP should not
>>>> anticipate or depend on any specific ou
gt; >> tree consumers of these APIs in any way, for compatibility,
> upgradeability
> >> or anything. There’s a lot that needs to be done over the coming years
> to
> >> improve the internal structure of the project, and unduly entrenching
> the
> >> current
t that needs to be done over the coming years to
>> improve the internal structure of the project, and unduly entrenching the
>> current state of affairs would be a huge potential harm of these efforts to
>> modularise the codebase.
>>
>> From: David Capwell
>>
ching the
> current state of affairs would be a huge potential harm of these efforts to
> modularise the codebase.
>
> From: David Capwell
> Date: Tuesday, 9 November 2021 at 23:38
> To: dev@cassandra.apache.org
> Subject: Re: [DISCUSS] CEP-17: SSTable format API (CASSANDRA-17
of the project, and unduly entrenching the current state
of affairs would be a huge potential harm of these efforts to modularise the
codebase.
From: David Capwell
Date: Tuesday, 9 November 2021 at 23:38
To: dev@cassandra.apache.org
Subject: Re: [DISCUSS] CEP-17: SSTable format API (CASSANDRA
ing the
> compatibility work.
>
>
> From: Jeremiah D Jordan
> Date: Tuesday, 9 November 2021 at 19:43
> To: Cassandra DEV
> Subject: Re: [DISCUSS] CEP-17: SSTable format API (CASSANDRA-17056)
> I would love to have this discussion and setup annotations or similar to
>
localising the compatibility work.
From: Jeremiah D Jordan
Date: Tuesday, 9 November 2021 at 19:43
To: Cassandra DEV
Subject: Re: [DISCUSS] CEP-17: SSTable format API (CASSANDRA-17056)
I would love to have this discussion and setup annotations or similar to
formalize things. I just do not think we
> I would be happy to go through and try to put together something for that ...
> At the very least it should get its own DISCUSS thread and then be written
> up in the wiki.
+1. Thanks.
> On Nov 9, 2021, at 11:43 AM, Jeremiah D Jordan
> wrote:
>
> I would love to have this discussion and s
I would love to have this discussion and setup annotations or similar to
formalize things. I just do not think we need to hold any up CEPs to do so.
That discussion should possibly be a CEP of its own proposing how we want to
formalize interfaces? I would be happy to go through and try to put
>
> trunk -> anything goes, not trunk -> try not to change these interfaces
Have we ever clarified what "these interfaces" are? Was just talking to
David and I realized I didn't even JavaDoc CommitLogReadHandler as _being
designed_ for external usage. /sigh
I think it'd be valuable for us to go t
> We already have many interfaces similar to these for Compaction Strategy,
> Indexing, Query Handler.
Today-I-Learned QueryHandler is not allowed to be touched in a minor… good to
know…
> not trunk -> try not to change these interfaces
Outside of MBeans, I honestly do not know what interfaces
We already have many interfaces similar to these for Compaction Strategy,
Indexing, Query Handler. I would hope that commiters are already following a
policy along the lines of trunk -> anything goes, not trunk -> try not to
change these interfaces. I would expect that to be the same policy fo
I still have one outstanding comment, but this is a comment for several of the
CEPs being worked on
> And last comment, which I have also done in the other modularity thread…
> backwards compatibility and maintenance. It is not clear right now what java
> interfaces may not break and how we can
Does anyone have any further comments or questions on the proposal, or are
we ready to move forward to a vote?
Regards,
Branimir
On Tue, Nov 2, 2021 at 7:15 PM David Capwell
wrote:
> > I apologize I did not mention those things explicitly. All the places
> where
> > sstable files are accessed
> I apologize I did not mention those things explicitly. All the places where
> sstable files are accessed directly would have to be refactored.
Works for me
> Speaking about the implementation, one idea I was thinking about was that
> the factories for formats are registered using Java's native
David,
I apologize I did not mention those things explicitly. All the places where
sstable files are accessed directly would have to be refactored.
Regarding TableMetrics - currently it includes many metrics, some of them
are unrelated to sstables at all, but there are metrics which are specific
gt; express our preferences and defer to the collective opinion where possible.
>> True -1s should very rarely appear.
>>>
>>>
>>> From: David Capwell
>>> Date: Wednesday, 27 October 2021 at 15:33
>>> To: dev@cassandra.apache.org
>>> Subject:
ealise this
> isn’t a vote thread, but the effect is the same. IMO we should try to
> express our preferences and defer to the collective opinion where possible.
> True -1s should very rarely appear.
> >
> >
> > From: David Capwell
> > Date: Wednesday, 27 October 202
ess our
> preferences and defer to the collective opinion where possible. True -1s
> should very rarely appear.
>
>
> From: David Capwell
> Date: Wednesday, 27 October 2021 at 15:33
> To: dev@cassandra.apache.org
> Subject: Re: [DISCUSS] CEP-17: SSTable format API (CASSANDRA-
5:33
To: dev@cassandra.apache.org
Subject: Re: [DISCUSS] CEP-17: SSTable format API (CASSANDRA-17056)
Reading the CEP I don’t see any mention to the systems which access SSTables;
such as streaming (small callout to zero-copy-streaming with
ZeroCopyBigTableWriter) and repair. If you are abs
Reading the CEP I don’t see any mention to the systems which access SSTables;
such as streaming (small callout to zero-copy-streaming with
ZeroCopyBigTableWriter) and repair. If you are abstracting out BigTableReader
then you are not dealing with the implementation assumptions that users of
SS
Hi Stefan,
That idea is not related to this CEP which is about the file formats of the
sstables, not file system access. But you should take a look at the work
recently committed in https://issues.apache.org/jira/browse/CASSANDRA-16926
to switch to using java.nio.file.Path for file access. This s
One point I would like to add to this; I was already looking into how
to extend this but what I saw in SSTableReader was that it is very
much "file system oriented". There was not any possibility to actually
hook something like that there. I think what importing does is that it
will use SSTableRead
Hi Jacek,
Thanks for taking the lead on this.
There was importing of SSTables introduced in 4.0 via
StorageService#importNewSSTables. The "problem" with this is that
SSTables need to be physically located at disk so Cassandra can read
them. If a backup is taken and SSTables are uploaded to, for e
I'd like to start a discussion about SSTable format API proposal (CEP-17)
Jira: https://issues.apache.org/jira/browse/CASSANDRA-17056
CEP:
https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-17%3A+SSTable+format+API
Thanks,
Jacek
---
26 matches
Mail list logo
