Need help with modl?
Click the “chat” button below for chat support from the developer who created it, or find similar developers for support.

About the developer

466 Stars 51 Forks MIT License 196 Commits 29 Opened issues


golang database modelling library

Services available


Need anything else?

Contributors list

Modl: Go database model & mapping

Build Status Godoc

Modl is a library which provides database modelling and mapping. It is a fork of James Cooper's wonderful gorp.

Note. Modl's public facing interface is considered unfinished and open to change. The current API will not be broken lightly, but additions are likely. As Gorp's behavior moves on, Modl may adopt some of it or may not.


Modl's goal is to clean up bits of gorp's API, add some additional features like query building helpers and additional control over SQL generation, and to reuse lower level abstractions provided in sqlx. The driving philosophies behind modl are:

  • If something can be done in
    , do it that way
  • Go is not a good declarative language, do not abuse struct tags
  • Expose as much as possible to facilitate extension by other libraries
  • Avoid abstractions which provide initial convenience but must eventually be abandoned
  • Avoid reflect and cache its results where possible, use where necessary


  • Bind struct models to tables
  • CRUD helpers for bound structs
  • Create schema from database model (great for testing)
  • Pre/post insert/update/delete hooks
  • Automatic binding of auto increment PKs after insert
  • Delete & Fetch by primary keys (w/ multi-key support)
  • Sql trace logging
  • Bind arbitrary SQL queries to a struct
  • Optional optimistic locking using a version column (for update/deletes)

Differences from Gorp

Since modl is a gorp fork, here are some of its major behavioral differences:

  • Field names are mapped to all-lowercase sql equivalents. Capitalization is an artifact of visibility, and this was required for compatibility with
  • No more struct/slice returns, pass pointers to methods instead
  • Many panics in gorp are errors in modl
  • TypeConverters are removed in favor of implementing
    for custom types.


To use the

script, set the following environment variables:
# mysql DSN, note parseTime arg for time scanning support:
MODL_MYSQL_DSN="username:[email protected]/dbname?parseTime=true"

postgres DSN, like:

MODL_POSTGRES_DSN="user=username password=pw dbname=dbname sslmode=disable"

sqlite DSN, which is a path


optional, will fail the test if any DBs are skipped (for CI, mostly)


In addition to this, you can create an

file in this directory which will be sourced and ignored by git. You can continue to use the
variables if you want to manually run
go test
or if you want to run the benchmarks, as described below.

The original follows:

API Stability

The API of Modl has been quite stable since its conception. Changes to the API are avoided as much as possible but there is currently no promise of forward or backward compatibility.

Supported Databases

Modl relies heavily upon the

package, and has a Dialect interface which can be used to smooth over differences between databases. There is a list of sql drivers on the Go wiki, most of which Modl should be compatible with. Dialects are provided for:
  • MySQL
  • PostgreSQL
  • sqlite3

The test suite is continuously run against all of these databases.


API Documentation is available on godoc.


Modl performs similar to Gorp. There are benchmarks in

which will benchmark native querying w/
and manual Scanning with what modl does. Modl should perform between 2-3% slower than hand-done SQL.


The original contributors to gorp are:

  • @coopernurse - James Cooper
  • @robfig - Rob Figueiredo
  • @sqs - Quinn Slack
  • matthias-margush - column aliasing via tags

We use cookies. If you continue to browse the site, you agree to the use of cookies. For more information on our use of cookies please see our Privacy Policy.