[
https://issues.apache.org/jira/browse/CASSANDRA-7443?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14043470#comment-14043470
]
Sylvain Lebresne commented on CASSANDRA-7443:
---------------------------------------------
Before people get too deep on this, I just want to note that a priori, I have a
relatively strong feeling against "pluggable storage engine" if it's an
"external feature" (where there would be competing engines). Because I think
it would be a disservice to make to Cassandra in general. Multiple engines
means that some users will pick the "wrong" one with generally little or no way
to change, it complicates testing/maintenance and it can easily limit changes
because "that would broke the assumption that engine X or Y uses".
Please note however that I have no problem at all with cleaning up internal
APIs so it's easier for us to experiment with changes/improvements, and if
that's really just what we're talking about here, I'm +1. But if we're talking
about providing some form of external guarantee on those API and making it
"official" that people can bring their own storage engine, then be aware that I
will need a serious amount of convincing.
> SSTable Pluggability v2
> -----------------------
>
> Key: CASSANDRA-7443
> URL: https://issues.apache.org/jira/browse/CASSANDRA-7443
> Project: Cassandra
> Issue Type: Bug
> Components: Core
> Reporter: T Jake Luciani
> Assignee: T Jake Luciani
> Fix For: 3.0
>
>
> As part of a wider effort to improve the performance of our storage engine we
> will need to support basic pluggability of the SSTable reader/writer. We
> primarily need this to support the current SSTable format and new SSTable
> format in the same version. This will also let us encapsulate the changes in
> a single layer vs forcing the whole engine to change at once.
> We previously discussed how to accomplish this in CASSANDRA-3067
>
--
This message was sent by Atlassian JIRA
(v6.2#6252)
