Database-agnostic user model in Golang

Question

I'm trying to design a database model for an API. So far, here's my attempt to do so:

I have a package called models that contains all of the models. Here, User is the database model and UserStorer is an interface that should be implemented by any store (e.g. postgres, mongodb etc.)

package models
//User represents an application user
type User struct {
 ID int64
 Email string
 Password string
 FirstName string
 MiddleName string
 LastName string
}
...
//UserStorer represents a user store
//this can be used to store user on different
//data store
type UserStorer interface {
 List(...UserFilter) ([]User, error)
 Get(...UserFilter) (User, error)
 Create(User) error
 Update(User) error
 Delete(...UserFilter) error
}

Then I have a package called store, which contains the implementations of model stores like UserStorer

package store
import (
 "github.com/jmoiron/sqlx"
 "github.com/steven-ferrer/go-db-models/models"
)
//UserStore implements models.UserStorer
type UserStore struct {
 db *sqlx.DB
}
func (cs *UserStore) List(filters ...models.UserFilter) ([]models.User, error) {
 return nil, nil
}
func (cs *UserStore) Get(filters ...models.UserFilter) (models.User, error) {
 return models.User{}, nil
}
func (cs *UserStore) Create(User models.User) error {
 return nil
}
func (cs *UserStore) Update(User models.User) error {
 return nil
}
func (cs *UserStore) Delete(filters ...models.UserFilter) error {
 return nil
}
func NewUserStore(db *sqlx.DB) models.UserStorer {
 return &UserStore{db}
}

The question is, am I doing it right? If not, how do I improve it?

Here is the repo of the example that I used: https://github.com/steven-ferrer/go-db-models

• Benjam: Did you test it? Did it work? It looks good to me, but testing might show you where things need to be adjusted.
• stevenferrer: I've tried implementing a UserStore using postgresql as database and it worked fine. I just need to know if i'm on the right direction or if there are anything that I can improve on this.

Answer 1

I like your approach:

1. First you've defined an interface on accepting side of application. So you can fix requirements to parts responsible for storage.

2. Realisation is not tied to interface. Today you may use PostgreSQL, later you may add some sharding on application side, or even migrate to another DB. Keeping db-related logic in one place helps you do it in future.

3. Next you can cover it with tests to ensure logics won't get broken in future impovements.

• stevenferrer: my first idea was to store each model on a separate package, say the import path would be example.com/foo/models/users, then you would have users.User, users.Filter users.FilterConfig, users.Store. Do you think it would make sense?
• Eugene Lisitsky: Depends on application and how components are tied together. I think it's ok group models by domains: separate users and objects an so on. And if you need some submodules place subpackages in them/
• stevenferrer: i'm not sure if i completely understand your suggestion, could you please give a concrete example?
• Eugene Lisitsky: Unfortunately can't show an example at a moment ( I mean to keep together. It's good to start as you proposed with users.User etc. An then when it will be necessary group in bigger packages.