Introduce Database interface. #267
Conversation
All required database functionality is now defined in a new Database interface. Almost all of the production code has been updated to only handle this interface, rather than any concrete db implementations. This should enable the bbolt implementation to be switched out for a postgres implementation in future.
pool/database.go
Outdated
| loadLastPaymentCreatedOn() (int64, error) | ||
|
|
||
| // Account | ||
| FetchAccount(id string) (*Account, error) |
There was a problem hiding this comment.
I suspect almost all the functions required by the interface here could be unexported. Will look into doing that if you decide against it in this PR.
pool/hub.go
Outdated
| @@ -142,7 +141,7 @@ type HubConfig struct { | |||
| type Hub struct { | |||
| clients int32 // update atomically. | |||
|
|
|||
| db *bolt.DB | |||
| db Database | |||
There was a problem hiding this comment.
Just noticed he hub config and the hub all have references to the db, likely oversight on my part. I think we should remove one however: the hub reference I'm thinking.
There was a problem hiding this comment.
Personally I think removing the one from config makes more sense. The database is one dependency, the config is another. Each is a saparate thing with distinct responsibilities - the config holds simple values which define how the hub should behave, the database is a persistent storage device.
There was a problem hiding this comment.
On second thought, I wont make that change because that will conflict with how the rest of the dcrpool components are setup. They all have the database stored in their config, so I will maintain that for hub as well.
pool/job.go
Outdated
| @@ -48,10 +48,10 @@ func NewJob(header string, height uint32) *Job { | |||
| } | |||
|
|
|||
| // FetchJob fetches the job referenced by the provided id. | |||
| func FetchJob(db *bolt.DB, id string) (*Job, error) { | |||
| func (db *BoltDB) FetchJob(id string) (*Job, error) { | |||
There was a problem hiding this comment.
Perhaps all the BoltDB interface implementations need to go into a separate file? Or do you plan on adding the postgres implementations to the struct files as well?
There was a problem hiding this comment.
That's something we need to discuss. We could take either approach, but tbh I think both are kind of ugly 😂
I havent moved the funcs in this PR simply because it would make the changeset massive, and the review painful.
There was a problem hiding this comment.
Sure thing, let's resolve this in a separate PR.
All required database functionality is now defined in a new Database interface. Almost all of the production code has been updated to only handle this interface, rather than any concrete db implementations. This should enable the bbolt implementation to be switched out for a postgres implementation in future.
A big step for #257