Kallax is a PostgreSQL typesafe ORM for the Go language.
It aims to provide a way of programmatically write queries and interact with a PostgreSQL database without having to write a single line of SQL, use strings to refer to columns and use values of any type in queries.
For that reason, the first priority of kallax is to provide type safety to the data access layer.
Another of the goals of kallax is make sure all models are, first and foremost, Go structs without having to use database-specific types such as, for example, sql.NullInt64
.
Support for arrays of all basic Go types and all JSON and arrays operators is provided as well.
- Installation
- Usage
- Define models
- Model schema
- Manipulate models
- Query models
- Transactions
- Caveats
- Migrations
- Custom operators
- Debug SQL queries
- Benchmarks
- Acknowledgements
- Contributing
The recommended way to install kallax
is:
go get -u gopkg.in/src-d/go-kallax.v1/...
kallax includes a binary tool used by go generate, please be sure that
$GOPATH/bin
is on your$PATH
Imagine you have the following file in the package where your models are.
package models
type User struct {
kallax.Model `table:"users" pk:"id"`
ID kallax.ULID
Username string
Email string
Password string
}
Then put the following on any file of that package:
//go:generate kallax gen
Now all you have to do is run go generate ./...
and a kallax.go
file will be generated with all the generated code for your model.
If you don't want to use go generate
, even though is the preferred use, you can just go to your package and run kallax gen
yourself.
Sometimes you might want to use the generated code in the same package it is defined and cause problems during the generation when you regenerate your models. You can exclude files in the package by changing the go:generate
comment to the following:
//go:generate kallax gen -e file1.go -e file2.go
A model is just a Go struct that embeds the kallax.Model
type. All the fields of this struct will be columns in the database table.
A model also needs to have one (and just one) primary key. The primary key is defined using the pk
struct tag on the kallax.Model
embedding. You can also set the primary key in a field of the struct with the struct tag pk
, which can be pk:""
for a non auto-incrementable primary key or pk:"autoincr"
for one that is auto-incrementable.
More about primary keys is discussed at the primary keys section.
First, let's review the rules and conventions for model fields:
- All the fields with basic types or types that implement sql.Scanner and driver.Valuer will be considered a column in the table of their matching type.
- Arrays or slices of types mentioned above will be treated as PostgreSQL arrays of their matching type.
- Fields that are structs (or pointers to structs) or interfaces not implementing sql.Scanner and driver.Valuer will be considered as JSON. Same with arrays or slices of types that follow these rules.
- Fields that are structs (or pointers to structs) with the struct tag
kallax:",inline"
or are embedded will be considered inline, and their fields would be considered as if they were at the root of the model. - All pointer fields are nullable by default. That means you do not need to use
sql.NullInt64
,sql.NullBool
and the likes because kallax automatically takes care of that for you. WARNING: all JSON andsql.Scanner
implementors will be initialized withnew(T)
in case they arenil
before they are scanned. - By default, the name of a column will be the name of the struct field converted to lower snake case (e.g.
UserName
=>user_name
,UserID
=>user_id
). You can override it with the struct tagkallax:"my_custom_name"
. - Slices of structs (or pointers to structs) that are models themselves will be considered a 1:N relationship. Arrays of models are not supported by design.
- A struct or pointer to struct field that is a model itself will be considered a 1:1 relationship.
- For relationships, the foreign key is assumed to be the name of the model converted to lower snake case plus
_id
(e.g.User
=>user_id
). You can override this with the struct tagfk:"my_custom_fk"
. - For inverse relationship, you need to use the struct tag
fk:",inverse"
. You can combine theinverse
with overriding the foreign key withfk:"my_custom_fk,inverse"
. In the case of inverses, the foreign key name does not specify the name of the column in the relationship table, but the name of the column in the own table. The name of the column in the other table is always the primary key of the other model and cannot be changed for the time being. - Foreign keys do not have to be in the model, they are automagically managed underneath by kallax.
Kallax also provides a kallax.Timestamps
struct that contains CreatedAt
and UpdatedAt
that will be managed automatically.
Let's see an example of models with all these cases:
type User struct {
kallax.Model `table:"users" pk:"id,autoincr"`
kallax.Timestamps
ID int64
Username string
Password string
Emails []string
// This is for demo purposes, please don't do this
// 1:N relationships load all N rows by default, so
// only do it when N is small.
// If N is big, you should probably be querying the posts
// table instead.
Posts []*Post `fk:"poster_id"`
}
type Post struct {
kallax.Model `table:"posts"`
kallax.Timestamps
ID int64 `pk:"autoincr"`
Content string `kallax:"post_content"`
Poster *User `fk:"poster_id,inverse"`
Metadata Metadata `kallax:",inline"`
}
type Metadata struct {
MetadataType MetadataType
Metadata map[string]interface{} // this will be json
}
Tag | Description | Can be used in |
---|---|---|
table:"table_name" |
Specifies the name of the table for a model. If not provided, the name of the table will be the name of the struct in lower snake case (e.g. UserPreference => user_preference ) |
embedded kallax.Model |
pk:"primary_key_column_name" |
Specifies the column name of the primary key. | embedded kallax.Model |
pk:"primary_key_column_name,autoincr" |
Specifies the column name of the autoincrementable primary key. | embedded kallax.Model |
pk:"" |
Specifies the field is a primary key | any field with a valid identifier type |
pk:"autoincr" |
Specifies the field is an auto-incrementable primary key | any field with a valid identifier type |
kallax:"column_name" |
Specifies the name of the column | Any model field that is not a relationship |
kallax:"-" |
Ignores the field and does not store it | Any model field |
kallax:",inline" |
Adds the fields of the struct field to the model. Column name can also be given before the comma, but it is ignored, since the field is not a column anymore | Any struct field |
fk:"foreign_key_name" |
Name of the foreign key column | Any relationship field |
fk:",inverse" |
Specifies the relationship is an inverse relationship. Foreign key name can also be given before the comma | Any relationship field |
unique:"true" |
Specifies the column has an unique constraint. | Any non-primary key field |
Primary key types need to satisfy the Identifier interface. Even though they have to do that, the generator is smart enough to know when to wrap some types to make it easier on the user.
The following types can be used as primary key:
int64
uuid.UUID
kallax.ULID
: this is a type kallax provides that implements a lexically sortable UUID. You can store it asuuid
like any other UUID, but internally it's an ULID and you will be able to sort lexically by it.
If you need another type as primary key, feel free to open a pull request implementing that.
Known limitations
- Only one primary key can be specified and it can't be a composite key.
Kallax generates a constructor for your type named New{TypeName}
. But you can customize it by implementing a private constructor named new{TypeName}
. The constructor generated by kallax will use the same signature your private constructor has. You can use this to provide default values or construct the model with some values.
If you implement this constructor:
func newUser(username, password string, emails ...string) (*User, error) {
if username != "" || len(emails) == 0 || password != "" {
return errors.New("all fields are required")
}
return &User{Username: username, Password: password, Emails: emails}
}
Kallax will generate one with the following signature:
func NewUser(username string, password string, emails ...string) (*User, error)
IMPORTANT: if your primary key is not auto-incrementable, you should set an ID for every model you create in your constructor. Or, at least, set it before saving it. Inserting, updating, deleting or reloading an object with no primary key set will return an error.
If you don't implement your own constructor it's ok, kallax will generate one for you just instantiating your object like this:
func NewT() *T {
return new(T)
}
Events can be defined for models and they will be invoked at certain times of the model lifecycle.
BeforeInsert
: will be called before inserting the model.BeforeUpdate
: will be called before updating the model.BeforeSave
: will be called before updating or inserting the model. It's always called beforeBeforeInsert
andBeforeUpdate
.BeforeDelete
: will be called before deleting the model.AfterInsert
: will be called after inserting the model. The presence of this event will cause the insertion of the model to run in a transaction. If the event returns an error, it will be rolled back.AfterUpdate
: will be called after updating the model. The presence of this event will cause the update of the model to run in a transaction. If the event returns an error, it will be rolled back.AfterSave
: will be called after updating or inserting the model. It's always called afterAfterInsert
andAfterUpdate
. The presence of this event will cause the operation with the model to run in a transaction. If the event returns an error, it will be rolled back.AfterDelete
: will be called after deleting the model. The presence of this event will cause the deletion to run in a transaction. If the event returns an error, it will be rolled back.
To implement these events, just implement the following interfaces. You can implement as many as you want:
- BeforeInserter
- BeforeUpdater
- BeforeSaver
- BeforeDeleter
- AfterInserter
- AfterUpdater
- AfterSaver
- AfterDeleter
Example:
func (u *User) BeforeSave() error {
if u.Password == "" {
return errors.New("cannot save user without password")
}
if !isCrypted(u.Password) {
u.Password = crypt(u.Password)
}
return nil
}
Kallax generates a bunch of code for every single model you have and saves it to a file named kallax.go
in the same package.
For every model you have, kallax will generate the following for you:
- Internal methods for your model to make it work with kallax and satisfy the Record interface.
- A store named
{TypeName}Store
: the store is the way to access the data. A store of a given type is the way to access and manipulate data of that type. You can get an instance of the type store withNew{TypeName}Store(*sql.DB)
. - A query named
{TypeName}Query
: the query is the way you will be able to build programmatically the queries to perform on the store. A store only will accept queries of its own type. You can create a new query withNew{TypeName}Query()
. The query will contain methods for adding criteria to your query for every field of your struct, calledFindBy
s. The query object is not immutable, that is, every condition added to it, changes the query. If you want to reuse part of a query, you can call theCopy()
method of a query, which will return a query identical to the one used to call the method. - A resultset named
{TypeName}ResultSet
: a resultset is the way to iterate over and obtain all elements in a resultset returned by the store. A store of a given type will always return a result set of the matching type, which will only return records of that type. - Schema of all the models containing all the fields. That way, you can access the name of a specific field without having to use a string, that is, a typesafe way.
A global variable Schema
will be created in your kallax.go
, that contains a field with the name of every of your models. Those are the schemas of your models. Each model schema contains all the fields of that model.
So, to access the username field of the user model, it can be accessed as:
Schema.User.Username
For all of the following sections, we will assume we have a store store
for our model's type.
To insert a model we just need to use the Insert
method of the store and pass it a model. If the primary key is not auto-incrementable and the object does not have one set, the insertion will fail.
user := NewUser("fancy_username", "super_secret_password", "[email protected]")
err := store.Insert(user)
if err != nil {
// handle error
}
If our model has relationships, they will be saved, and so will the relationships of the relationships and so on. TL;DR: inserts are recursive.
Note: the relationships will be saved using Save
, not Insert
.
user := NewUser("foo")
user.Posts = append(user.Posts, NewPost(user, "new post"))
err := store.Insert(user)
if err != nil {
// handle error
}
If there are any relationships in the model, both the model and the relationships will be saved in a transaction and only succeed if all of them are saved correctly.
To insert a model we just need to use the Update
method of the store and pass it a model. It will return an error if the model was not already persisted or has not an ID.
user := FindLast()
rowsUpdated, err := store.Update(user)
if err != nil {
// handle error
}
By default, when a model is updated, all its fields are updated. You can also specify which fields to update passing them to update.
rowsUpdated, err := store.Update(user, Schema.User.Username, Schema.User.Password)
if err != nil {
// handle error
}
If our model has relationships, they will be saved, and so will the relationships of the relationships and so on. TL;DR: updates are recursive.
Note: the relationships will be saved using Save
, not Update
.
user := FindLastPoster()
rowsUpdated, err := store.Update(user)
if err != nil {
// handle error
}
If there are any relationships in the model, both the model and the relationships will be saved in a transaction and only succeed if all of them are saved correctly.
To save a model we just need to use the Save
method of the store and pass it a model. Save
is just a shorthand that will call Insert
if the model is not yet persisted and Update
if it is.
updated, err := store.Save(user)
if err != nil {
// handle error
}
if updated {
// it was updated, not inserted
}
If our model has relationships, they will be saved, and so will the relationships of the relationships and so on. TL;DR: saves are recursive.
user := NewUser("foo")
user.Posts = append(user.Posts, NewPost(user, "new post"))
updated, err := store.Save(user)
if err != nil {
// handle error
}
If there are any relationships in the model, both the model and the relationships will be saved in a transaction and only succeed if all of them are saved correctly.
To delete a model we just have to use the Delete
method of the store. It will return an error if the model was not already persisted.
err := store.Delete(user)
if err != nil {
// handle error
}
Relationships of the model are not automatically removed using Delete
.
For that, specific methods are generated in the store of the model.
For one to many relationships:
// remove specific posts
err := store.RemovePosts(user, post1, post2, post3)
if err != nil {
// handle error
}
// remove all posts
err := store.RemovePosts(user)
For one to one relationships:
// remove the thing
err := store.RemoveThing(user)
Note that for that to work, the thing you're deleting must not be empty. That is, you need to eagerly load (or set afterwards) the relationships.
user, err := store.FindOne(NewUserQuery())
checkErr(err)
// THIS WON'T WORK! We've not loaded "Things"
err := store.RemoveThings(user)
user, err := store.FindOne(NewUserQuery().WithThings())
checkErr(err)
// THIS WILL WORK!
err := store.RemoveThings(user)
To perform a query you have to do the following things:
- Create a query
- Pass the query to
Find
,FindOne
,MustFind
orMustFindOne
of the store - Gather the results from the result set, if the used method was
Find
orMustFind
// Create the query
q := NewUserQuery().
Where(kallax.Like(Schema.User.Username, "joe%")).
Order(kallax.Asc(Schema.User.Username)).
Limit(20).
Offset(2)
rs, err := store.Find(q)
if err != nil {
// handle error
}
for rs.Next() {
user, err := rs.Get()
if err != nil {
// handle error
}
}
Next will automatically close the result set when it hits the end. If you have to prematurely exit the iteration you can close it manually with rs.Close()
.
You can query just a single row with FindOne
.
q := NewUserQuery().
Where(kallax.Eq(Schema.User.Username, "Joe"))
user, err := store.FindOne(q)
You can also get all of the rows in a result without having to manually iterate the result set with FindAll
.
q := NewUserQuery().
Where(kallax.Like(Schema.User.Username, "joe%")).
Order(kallax.Asc(Schema.User.Username)).
Limit(20).
Offset(2)
users, err := store.FindAll(q)
if err != nil {
// handle error
}
By default, all columns in a row are retrieved. To not retrieve all of them, you can specify the columns to include/exclude. Take into account that partial records retrieved from the database will not be writable. To make them writable you will need to Reload
the object.
// Select only Username and password
NewUserQuery().Select(Schema.User.Username, Schema.User.Password)
// Select all but password
NewUserQuery().SelectNot(Schema.User.Password)
Kallax generates a FindBy
for every field of your model for which it makes sense to do so. What is a FindBy
? It is a shorthand to add a condition to the query for a specific field.
Consider the following model:
type Person struct {
kallax.Model
ID int64 `pk:"autoincr"`
Name string
BirthDate time.Time
Age int
}
Four FindBy
s will be generated for this model:
func (*PersonQuery) FindByID(...int64) *PersonQuery
func (*PersonQuery) FindByName(string) *PersonQuery
func (*PersonQuery) FindByBirthDate(kallax.ScalarCond, time.Time) *PersonQuery
func (*PersonQuery) FindByAge(kallax.ScalarCond, int) *PersonQuery
That way, you can just do the following:
NewPersonQuery().
FindByAge(kallax.GtOrEq, 18).
FindByName("Bobby")
instead of:
NewPersonQuery().
Where(kallax.GtOrEq(Schema.Person.Age, 18)).
Where(kallax.Eq(Schema.Person.Name, "Bobby"))
Why are there three different types of methods generated?
- The primary key field is treated in a special way and allows multiple IDs to be passed, since searching by multiple IDs is a common operation.
- Types that are not often searched by equality (integers, floats, times, ...) allow an operator to be passed to them to determine the operator to use.
- Types that can only be searched by value (strings, bools, ...) only allow a value to be passed.
Instead of passing the query to Find
or FindOne
, you can pass it to Count
to get the number of rows in the resultset.
n, err := store.Count(q)
By default, no relationships are retrieved unless the query specifies so.
For each of your relationships, a method in your query is created to be able to include these relationships in your query.
One to one relationships:
// Select all posts including the user that posted them
q := NewPostQuery().WithPoster()
rs, err := store.Find(q)
One to one relationships are always included in the same query. So, if you have 4 one to one relationships and you want them all, only 1 query will be done, but everything will be retrieved.
One to many relationships:
// Select all users including their posts
// NOTE: this is a really bad idea, because all posts will be loaded
// if the N side of your 1:N relationship is big, consider querying the N store
// instead of doing this
// A condition can be passed to the `With{Name}` method to filter the results.
q := NewUserQuery().WithPosts(nil)
rs, err := store.Find(q)
To avoid the N+1 problem with 1:N relationships, kallax performs batching in this case. So, a batch of users are retrieved from the database in a single query, then all the posts for those users and finally, they are merged. This process is repeated until there are no more rows in the result. Because of this, retrieving 1:N relationships is really fast.
The default batch size is 50, you can change this using the BatchSize
method all queries have.
NOTE: if a filter is passed to a With{Name}
method we can no longer guarantee that all related objects are there and, therefore, the retrieved records will not be writable.
If, for example, you have a model that is not writable because you only selected one field you can always reload it and have the full object. When the object is reloaded, all the changes made to the object that have not been saved will be discarded and overwritten with the values in the database.
err := store.Reload(user)
Reload will not reload any relationships, just the model itself. After a Reload
the model will always be writable.
You can query arbitrary JSON using the JSON operators defined in the kallax package. The schema of the JSON (if it's a struct, obviously for maps it is not) is also generated.
q := NewPostQuery().Where(kallax.JSONContainsAnyKey(
Schema.Post.Metadata,
"foo", "bar",
))
To execute things in a transaction the Transaction
method of the model store can be used. All the operations done using the store provided to the callback will be run in a transaction.
If the callback returns an error, the transaction will be rolled back.
store.Transaction(func(s *UserStore) error {
if err := s.Insert(user1); err != nil {
return err
}
return s.Insert(user2)
})
The fact that a transaction receives a store with the type of the model can be a problem if you want to store several models of different types. Kallax has a method named StoreFrom
that initializes a store of the type you want to have the same underlying store as some other.
store.Transaction(func(s *UserStore) error {
var postStore PostStore
kallax.StoreFrom(&postStore, s)
for _, p := range posts {
if err := postStore.Insert(p); err != nil {
return err
}
}
return s.Insert(user)
})
Transaction
can be used inside a transaction, but it does not open a new one, reuses the existing one.
- It is not possible to use slices or arrays of types that are not one of these types:
- Basic types (e.g.
[]string
,[]int64
) (except forrune
,complex64
andcomplex128
) - Types that implement
sql.Scanner
anddriver.Valuer
The reason why this is not possible is because kallax implements support for arrays of all basic Go types by hand and also for types implementingsql.Scanner
anddriver.Valuer
(using reflection in this case), but without having a common interface to operate on them, arbitrary types can not be supported. For example, consider the following typetype Foo string
, using[]Foo
would not be supported. Know that this will fail during the scanning of rows and not in code-generation time for now. In the future, might be moved to a warning or an error during code generation. Aliases of slice types are supported, though. If we havetype Strings []string
, usingStrings
would be supported, as a cast like this([]string)(&slice)
it's supported and[]string
is supported.
- Basic types (e.g.
time.Time
andurl.URL
need to be used as is. That is, you can not use a typeFoo
beingtype Foo time.Time
.time.Time
andurl.URL
are types that are treated in a special way, if you do that, it would be the same as sayingtype Foo struct { ... }
and kallax would no longer be able to identify the correct type.time.Time
fields will be truncated to remove its nanoseconds onSave
,Insert
orUpdate
, since PostgreSQL will not be able to store them. PostgreSQL stores times with timezones as UTC internally. So, times will come back as UTC (you can useLocal
method to convert them back to the local timezone). You can change the timezone that will be used to bring times back from the database in the PostgreSQL configuration.- Multidimensional arrays or slices are not supported except inside a JSON field.
Kallax can generate migrations for your schema automatically, if you want to. It is a process completely separated from the model generation, so it does not force you to generate your migrations using kallax.
Sometimes, kallax won't be able to infer a type or you will want a specific column type for a field. You can specify so with the sqltype
struct tag on a field.
type Model struct {
kallax.Model `table:"foo"`
Stuff SuperCustomType `sqltype:"bytea"`
}
You can see the full list of default type mappings between Go and SQL.
To generate a migration, you have to run the command kallax migrate
.
kallax migrate --input ./users/ --input ./posts/ --out ./migrations --name initial_schema
The migrate
command accepts the following flags:
Name | Repeated | Description | Default |
---|---|---|---|
--name or -n |
no | name of the migration file (will be converted to a_snakecase_name ) |
migration |
--input or -i |
yes | every occurrence of this flag will specify a directory in which kallax models can be found. You can specify multiple times this flag if you have your models scattered across several packages | required |
--out or -o |
no | destination folder where the migrations will be generated | ./migrations |
Every single migration consists of 2 files:
TIMESTAMP_NAME.up.sql
: script that will upgrade your database to this version.TIMESTAMP_NAME.down.sql
: script that will downgrade your database to this version.
Additionally, there is a lock.json
file where schema of the last migration is store to diff against the current models.
To run a migration you can either use kallax migrate up
or kallax migrate down
. up
will upgrade your database and down
will downgrade it.
These are the flags available for up
and down
:
Name | Description | Default |
---|---|---|
--dir or -d |
directory where your migrations are stored | ./migrations |
--dsn |
database connection string | required |
--steps or -s |
maximum number of migrations to run | 0 |
--all |
migrate all the way up (only available for up |
|
--version or -v |
final version of the database we want after running the migration. The version is the timestamp value at the beginning of migration files | 0 |
- If no
--steps
or--version
are provided todown
, they will do nothing. If--all
is provided toup
, it will upgrade the database all the way up. - If
--steps
and--version
are provided to eitherup
ordown
it will use only--version
, as it is more specific.
Example:
kallax migrate up --dir ./my-migrations --dsn 'user:pass@localhost:5432/dbname?sslmode=disable' --version 1493991142
Go type | SQL type |
---|---|
kallax.ULID |
uuid |
kallax.UUID |
uuid |
kallax.NumericID |
serial on primary keys, bigint on foreign keys |
int64 on primary keys |
serial |
int64 on foreign keys and other fields |
bigint |
string |
text |
rune |
char(1) |
uint8 |
smallint |
int8 |
smallint |
byte |
smallint |
uint16 |
integer |
int16 |
smallint |
uint32 |
bigint |
int32 |
integer |
uint |
numeric(20) |
int |
bigint |
int64 |
bigint |
uint64 |
numeric(20) |
float32 |
real |
float64 |
double |
bool |
boolean |
url.URL |
text |
time.Time |
timestamptz |
time.Duration |
bigint |
[]byte |
bytea |
[]T |
T'[] * where T' is the SQL type of type T , except for T = byte |
map[K]V |
jsonb |
struct |
jsonb |
*struct |
jsonb |
Any other type must be explicitly specified.
All types that are not pointers will be NOT NULL
.
You can create custom operators with kallax using the NewOperator
and NewMultiOperator
functions.
NewOperator
creates an operator with the specified format. It returns a function that given a schema field and a value returns a condition.
The format is a string in which :col:
will get replaced with the schema field and :arg:
will be replaced with the value.
var Gt = kallax.NewOperator(":col: > :arg:")
// can be used like this:
query.Where(Gt(SomeSchemaField, 9000))
NewMultiOperator
does exactly the same as the previous one, but it accepts a variable number of values.
var In = kallax.NewMultiOperator(":col: IN :arg:")
// can be used like this:
query.Where(In(SomeSchemaField, 4, 5, 6))
This function already takes care of wrapping :arg:
with parenthesis.
If you need further customization, you can create your own custom operator.
You need these things:
- A condition constructor (the operator itself) that takes the field and the values to create the proper SQL expression.
- A
ToSqler
that yields your SQL expression.
Imagine we want a greater than operator that only works with integers.
func GtInt(col kallax.SchemaField, n int) kallax.Condition {
return func(schema kallax.Schema) kallax.ToSqler {
// it is VERY important that all SchemaFields
// are qualified using the schema
return >Int{col.QualifiedName(schema), n}
}
}
type gtInt struct {
col string
val int
}
func (g *gtInt) ToSql() (sql string, params []interface{}, err error) {
return fmt.Sprintf("%s > ?", g.col), []interface{}{g.val}, nil
}
// can be used like this:
query.Where(GtInt(SomeSchemaField, 9000))
For most of the operators, NewOperator
and NewMultiOperator
are enough, so the usage of these functions is preferred over the completely custom approach. Use it only if there is no other way to build your custom operator.
It is possible to debug the SQL queries being executed with kallax. To do that, you just need to call the Debug
method of a store. This returns a new store with debugging enabled.
store.Debug().Find(myQuery)
This will log to stdout using log.Printf
kallax: Query: THE QUERY SQL STATEMENT, args: [arg1 arg2]
.
You can use a custom logger (any function with a type func(string, ...interface{})
using the DebugWith
method instead.
func myLogger(message string, args ...interface{}) {
myloglib.Debugf("%s, args: %v", message, args)
}
store.DebugWith(myLogger).Find(myQuery)
Here are some benchmarks against GORM, SQLBoiler and database/sql
. In the future we might add benchmarks for some more complex cases and other available ORMs.
BenchmarkKallaxUpdate-4 300 4179176 ns/op 656 B/op 25 allocs/op
BenchmarkKallaxUpdateWithRelationships-4 200 5662703 ns/op 6642 B/op 175 allocs/op
BenchmarkKallaxInsertWithRelationships-4 200 5648433 ns/op 10221 B/op 218 allocs/op
BenchmarkSQLBoilerInsertWithRelationships-4 100 17543073 ns/op 5898 B/op 185 allocs/op
BenchmarkRawSQLInsertWithRelationships-4 200 5427503 ns/op 4516 B/op 127 allocs/op
BenchmarkGORMInsertWithRelationships-4 200 6196277 ns/op 35080 B/op 610 allocs/op
BenchmarkKallaxInsert-4 300 3916239 ns/op 1218 B/op 29 allocs/op
BenchmarkSQLBoilerInsert-4 300 4356432 ns/op 1151 B/op 35 allocs/op
BenchmarkRawSQLInsert-4 300 4065924 ns/op 1052 B/op 27 allocs/op
BenchmarkGORMInsert-4 300 4398799 ns/op 4678 B/op 107 allocs/op
BenchmarkKallaxQueryRelationships/query-4 500 2900095 ns/op 269157 B/op 6200 allocs/op
BenchmarkSQLBoilerQueryRelationships/query-4 1000 2082963 ns/op 125587 B/op 5098 allocs/op
BenchmarkRawSQLQueryRelationships/query-4 20 59400759 ns/op 294176 B/op 11424 allocs/op
BenchmarkGORMQueryRelationships/query-4 300 4758555 ns/op 1069118 B/op 20833 allocs/op
BenchmarkKallaxQuery/query-4 3000 546742 ns/op 50673 B/op 1590 allocs/op
BenchmarkSQLBoilerQuery/query-4 2000 677839 ns/op 54082 B/op 2436 allocs/op
BenchmarkRawSQLQuery/query-4 3000 464498 ns/op 37480 B/op 1525 allocs/op
BenchmarkGORMQuery/query-4 1000 1388406 ns/op 427401 B/op 7068 allocs/op
PASS
ok gopkg.in/src-d/go-kallax.v1/benchmarks 44.899s
As we can see on the benchmark, the performance loss is not very much compared to raw database/sql
, while GORMs performance loss is very big and the memory consumption is way higher. SQLBoiler, on the other hand, has a lower memory footprint than kallax (in some cases), but a bigger performance loss (though not very significant in most cases), except for queries with relationships (that is a regression, though, and should be improved in the future).
Source code of the benchmarks can be found on the benchmarks folder.
Notes:
- Benchmarks were run on a 2015 MacBook Pro with i5 and 8GB of RAM and 128GB SSD hard drive running fedora 25.
- Benchmark of
database/sql
for querying with relationships is implemented with a very naive 1+n solution. That's why the result is that bad.
- Big thank you to the Masterminds/squirrel library, which is an awesome query builder used internally in this ORM.
- lib/pq, the Golang PostgreSQL driver that ships with a ton of support for builtin Go types.
- mattes/migrate, a Golang library to manage database migrations.
Kallax is a code generation tool, so it obviously has not been tested with all possible types and cases. If you find a case where the code generation is broken, please report an issue providing a minimal snippet for us to be able to reproduce the issue and fix it.
Kallax is a very opinionated ORM that works for us, so changes that make things not work for us or add complexity via configuration will not be considered for adding. If we decide not to implement the feature you're suggesting, just keep in mind that it might not be because it is not a good idea, but because it does not work for us or is not aligned with the direction we want kallax to be moving forward.
For obvious reasons, an instance of PostgreSQL is required to run the tests of this package.
By default, it assumes that an instance exists at 0.0.0.0:5432
with an user, password and database name all equal to testing
.
If that is not the case you can set the following environment variables:
DBNAME
: name of the databaseDBUSER
: database userDBPASS
: database user password
MIT, see LICENSE