ref(data): rds implementation as DB interface #158
Conversation
wrapping the current RDS implementation inside a generic data.DB interface contributes to #141
| // DB is an interface for managing a database | ||
| type DB interface { | ||
| Get() (*gorm.DB, error) | ||
| } |
There was a problem hiding this comment.
I don't think we need this interface. We used to have it, but removed it because there was no need for a factory to create multiple *gorm.DBs - just passing one around worked just fine. Is there a reason for adding this that I'm missing?
There was a problem hiding this comment.
I just added a commit that should answer that question. The interface will make it easier for us to slot in alternate (to RDS) db implementations, and for testing/mocking as well.
The question is: is this an effective approach toward the objectives outlined in #141?
There was a problem hiding this comment.
This abstraction will solve #141, but why not just pass around a *sql.DB? I removed this interface a while back because that abstraction already does everything we need
| dBInstance = os.Getenv(dBInstanceKey) | ||
| dBUser = os.Getenv(dBUserKey) | ||
| dBPass = os.Getenv(dBPassKey) | ||
| ) |
There was a problem hiding this comment.
it probably makes more sense to use envconfig or similar here. thoughts?
|
moving out of 2.2, as #162 was also moved |
wrapping the current RDS implementation inside a generic data.DB interface
contributes to #141