Hi Jeff,
Thanks a lot for your comments.
At your first question "Would this be implemented solely in the write path?”,
the answer is yes. I think enforcing it at reads/compaction/repairs may pose
problems for cases in which an alter table is performed adding new or more
strict constraints to
Separately, when we discuss benefits of a proposal in a CEP, we should talk about what’s concrete and ignore the stuff that’s idealistic. Of these four points:This brings to the table several benefits and flexibility. Some examples:Cassandra operators have more control to reason about your data and
Would this be implemented solely in the write path? Or would you also try to enforce it in the read and sstable/compaction/repair paths as well? On May 31, 2024, at 23:24, Bernardo Botella wrote:Hello everyone,I am proposing this CEP:CEP-42: Constraints Framework - CASSANDRA - Apache Software Fo
+1 to ban them, considering we also do not have any regular performance
testing as part of the project test suites.
Jacek has a good point about the checkstyle - there is separate one for
tests. Though I would not object if people want them banned from tests too.
I guess if we ban them this would
+1 (from the peanuts gallery)
Removing streams from anything that looks like an hot path is indeed a good
thing.
Please balance with 'don't fix things that aren't broken'.
While doing such changes seems a great idea, sometimes it may have side
effects that you don't see until you run on real dat
+1 agree with all this. Also fine to just use in tests or ban completely.On Jun 2, 2024, at 11:58 AM, Jake Luciani wrote:+1 Java streams cause perf issues in hot paths. Its fine for tests and slow paths. But for clairity its fine to ban it as well if the majority agrees. On Sun, Jun 2, 2024 at 1
