search

thelastpickle / cassandra-reaper

Automated Repair Awesomeness for Apache Cassandra
http://cassandra-reaper.io/
Apache License 2.0
490 stars 218 forks source link

Refactoring discussions #1265

Open Miles-Garnsey opened 1 year ago

Miles-Garnsey commented 1 year ago

Project board link

Reaper currently has a few idiosyncrasies which make it hard for new developers to get started.

  1. It is packaged by layer, not feature.
  2. Some of the layers reside in omnibus source files (e.g. CassandraStorage) which are hard to navigate.
  3. The CassandraStorage file passes around ResultSets and ResultSetFutures excessively, and it is hard to know what table those container objects are derived from. This makes these functions effectively untyped.

(There are probably more issues, these are just three that come to mind).

It might be interesting to investigate the possibility of evolving towards a package-by-feature approach to simplify ongoing maintenance of the codebase.

A first step (which would likely be useful even as a standalone initiative) might be to separate out the CassandraStorage and MemoryStorage functionality into DAOs for each type, and work to eliminate the passing of ResultSet(Futures) around.

This first step seems particularly helpful because (1) the CassandraStorage class is simply too big and has low cohesion, (2) the methods in that class are not really strongly typed, and (3) the application layer logical data model is quite different to the physical data model persisted in Cassandra (so the DAO layer is relatively thick).

┆Issue is synchronized with this Jira Story by Unito ┆Issue Number: REAP-73

Miles-Garnsey commented 1 year ago

Having spoken to Olivier in our team, he also recommends considering a longer term migration to using the object mapper in the storage layer.

I'm not typically a huge fan of ORMs, but I've used the mapper and it is probably the best ORM I've used, so I'd consider it to remove some boilerplate down the track. Just making a note here for further discussion.