-
Notifications
You must be signed in to change notification settings - Fork 3.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
core: refactoring projects #18779
Comments
See cockroachdb#18779. This doesn't carry out all the work but does all the basic required refactoring (mod cleanups). I don't love that we're passing `ReplicaEvalContext` through an interface. That should be avoidable and doing so should be instructive (I suspect we'll trim some fat in the process): Many methods roughly take the following form: ```go // GetMVCCStats returns the Replica's MVCCStats. func (rec ReplicaEvalContext) GetMVCCStats() enginepb.MVCCStats { r := rec.repl r.mu.RLock() defer r.mu.RUnlock() return *r.mu.state.Stats, nil } ``` and to define this method inside of the `batcheval` package, we'd have instead ```go type ReplicaEvalContext { // ... state struct { *sync.Mutex *storagebase.ReplicaState } } ``` though having to copy the mutex pointer smells fishy. Similar strategies can be used for most of the other methods. The downside is that `ReplicaEvalContext` will wind up being a struct with lots of pointers (i.e., perhaps a little large to sit in the hot path, though much smaller than BatchRequest!). We could accommodate that by arranging some of these pointers that never change (for example the `Engine` or the `AbortCache`) into a long-lived struct on `*Replica` instead.
@cuongdo, could I have a try for this part? |
@a6802739 The above checklist is a grab bag of refactoring ideas, not all of which may pan out. Give us some time to make a bit of progress on the margins and get a better feel for what the refactoring will look like. I'm sure there will be some tasks that emerge for you to tackle. |
@petermattis, Thank you very much. |
Also, as suggested in #18657 (comment): remove the locking of |
#19133 has some more abstract refactoring ideas on how to make the "non-raft" portion of Replica clearer. |
Introduce an interface implemented by `*Replica` and used by `ReplicaEvalContext` to prepare the way for moving `ReplicaEvalContext` into a subpackage of `storage`. See cockroachdb#18779.
Introduce an interface implemented by `*Replica` and used by `ReplicaEvalContext` to prepare the way for moving `ReplicaEvalContext` into a subpackage of `storage`. See cockroachdb#18779.
You'll notice that `EndTransaction` is still lingering in `replica_command.go`, but that will be done in a follow-up. Touches cockroachdb#18779.
You'll notice that `EndTransaction` is still lingering in `replica_command.go`, but that will be done in a follow-up. Touches cockroachdb#18779.
You'll notice that `EndTransaction` is still lingering in `replica_command.go`, but that will be done in a follow-up. Touches cockroachdb#18779.
Closing as there isn't anything very specific left here. |
This is a master list for core refactoring work. The theme is breaking up the massive
storage
package. Separate GitHub issues should be created as work or discussion begins on an item.Ideas:
TxnCoordSender
. This would add grepability and understandablity.RaftTransport
out ofstorage
raftScheduler
out ofstorage
BatchRequest
s to a separate packageAs you start to work on items, please put your name or GitHub id next to the task to claim it.
The text was updated successfully, but these errors were encountered: