go-gorp

gorp

Go2015–2018

go-gorp / gorp

gorp

Go Relational Persistence - an ORM-ish library for Go

Libraries & SDKs

Explore on GitHub Read Hacker News discussions

6Distinct people

7Mentions

0Explicit recommenders

3.7KGitHub stars

REPOSITORY AT A GLANCE

What to know before exploring

What it is

Go Relational Persistence - an ORM-ish library for Go

GitHub

Where it is used

No documented product use has been verified yet.

What people are saying

No recommendation phrase was found in the indexed comments.

No classified warning is attached to this page. Read the discussions before treating silence as approval.

Also in these discussions

No other repository is repeatedly linked in the same discussions.

This week on Hacker News

Nov 7–Nov 14 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/14/2026, 3:03:16 PM UTC.

No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.

Mentions over time

HN mentions by year7 dated mentions

Observed mentions: 2015-06-16 04:29:14 UTC to 2018-04-11 12:57:37 UTC.

Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.

View mention counts and date ranges

UTC ranges include their start and exclude their end. Select a period to filter the source evidence.
Period	Start (UTC)	End (exclusive, UTC)	Mentions	Comments
2015	2015-01-01 00:00:00 UTC	2016-01-01 00:00:00 UTC	2	2
2016	2016-01-01 00:00:00 UTC	2017-01-01 00:00:00 UTC	2	2
2017	2017-01-01 00:00:00 UTC	2018-01-01 00:00:00 UTC	1	1
2018	2018-01-01 00:00:00 UTC	2019-01-01 00:00:00 UTC	2	2

What Hacker News says

7 sources

majewsky·Apr 11, 2018

> What's your preferred approach to store table definitions and migrations? Schema versioning and ORM can be quite orthogonal, unless your ORM decides to be as opinionated about stuff as e.g. ActiveRecord. In Go, I use migrate [1] and Gorp [2]. Granted, I have to tell the column names to Gorp manually, but that is a minor annoyance which I'm happy to pay for clean separation of concerns. > Doesn't [using SQL for table definitions and migrations] make them more susceptible to mistakes? What mistakes do you have in mind? Typos etc. will be caught by tests that access the database. That leaves actual design errors, which can happen just as easily in ORM code as in SQL code. [1] https://github.com/mattes/migrate [2] https://github.com/go-gorp/gorp

In Ask HN: Raw SQL vs. ORM?

majewsky·Feb 16, 2018

Go optimizes for readability and lack of surprise at the expense of conciseness, which is why you feel it may not be productive. I think that the better maintainability vs. something like Rails massively outweighs the upfront cost of having to type more code, but other people might judge differently. Furthermore, Go emphasizes "doing it your own way". There are no big web frameworks in Go, you just pull in some small and rather orthogonal libraries and make up your own abstractions to tie them together as you build your application. The end result is something that's highly optimized for your personal needs, but it requires a certain way of thinking and working that's not for everyone (and not always desirable). Some people do better when given more freedom; those should prefer Go etc. Some people do better when working within a well-know

Read the rest

n set of rules; those should prefer Rails etc. Regarding ORM, I use Gorp (https://github.com/go-gorp/gorp) for INSERT, UPDATE, DELETE and basic SELECTs (e.g `SELECT * FROM things WHERE id = $1`), but when doing complex reports, I write SQL by hand [1] because ORMs are usually too constrained. I always feel like I know more SQL than the people who designed the ORM. [1] For example: https://github.com/sapcc/limes/blob/ab4245a8f195672b808f990f...

In Ask HN: Which stack do you use at your startup?

beliu·Feb 10, 2017

Another great resource for getting started is https://gobyexample.com/. Also check out usage examples on Sourcegraph (disclaimer: I'm the CTO). We sell our tool to companies to use on their private code, but a side effect is that we've indexed usage examples for just about every popular Go open-source library. For example, - Go std lib http package: https://sourcegraph.com/github.com/golang/go@bb41b4d599f5758... - Popular gorilla/mux routing library: https://sourcegraph.com/github.com/gorilla/mux@34bf6dc9faa08... - Gorp, a popular ORM-ish library: https://sourcegraph.com/github.com/go-gorp/gorp@033bf796a22f... Cross-repo jump-to-def + find-references = great for making sense of new code.

In Go Web Examples

aarondl0·Dec 15, 2016

I want to see the Go community and it's libraries flourish. But having libraries like this around which provide extra confusing and probably poorly maintained choices for users is detrimental to it's overall health. There's already great examples of maintenance rot found even amongst the very popular libraries like go-yaml and httprouter. One thing you can say about Go is it has 1000 Micro-frameworks, ORMs, Routers, and Logging libraries. Most of them are within a percent of giving the exact same feature set with the exact same approach and and ever so slightly different API. Lots of them share the same mistakes as they are a user's first project or a learning arena (though routing has been a pretty benchmarked area so that's been better than the others). As someone who has open source libraries, and who uses Go in their day job and at ho

Read the rest

me my personal opinion is that Go needs fewer, stronger libraries. Well supported, well maintained pieces rather than this illusion of choice that's presented today. I'm sorry if I came off as crass in my reply to the OP but that's simply the state I see in the community today. Ideally there'd be 2-4 ORMs in Go that would be the goto. And half would use a code-generation approach, half would use the reflection based approach. https://github.com/astaxie/beego/tree/master/orm https://github.com/cosiner/gomodel https://github.com/jinzhu/gorm https://github.com/go-gorp/gorp https://github.com/coocood/qbs https://github.com/go-reform/reform https://github.com/vattle/sqlboiler https://github.com/upper/db https://github.com/astaxie/beedb https://github.com/naoina/genmai https://github.com/monochromegane/argen https://github.com/square/squalor https://github.com/theduke/go-dukedb https://github.com/dropbox/godropbox/tree/master/database/sq... (...and more) And now: https://github.com/samonzeweb/godb Do we truly need this? This one in particular feels a lot like upperdb. And if it's for learning only, don't publish it to things like hackers news which makes people seem like it's something you should use as opposed to the more mature libraries out there. This is what I meant by fragmentation, it's an illusion of choice. There are actually very few logging/routing/orm/micro-framework libraries you should really use if you're serious about a project.

In Show HN: Godb is a simple Go ORM for PostgreSQL, MySQL, SQLite and SQL Server

whisk3rs·May 14, 2016

I generally have the same feeling, though https://github.com/go-gorp/gorp has worked very well for most of the database-heavy Go projects I've worked on over the last few years. It is just enough abstraction to be convenient and consistent and rarely gets in the way.

In Qb: Database toolkit for Go

dejawu·Nov 10, 2015

I've picked out the following that I like: - Gorp[1] for SQL stuff (I like that it "encourages" your program data structure to reflect your DB structure) - amber[2] for templating - gorilla/mux[3] for routing - gorilla/securecookie[4] for login/auth management (they have a sessions and context library too if you want that) Go also has libraries that handle basic versions of most of these tasks (and these third-party libraries extend them). If you're building something simple they might be sufficient. [1] https://github.com/go-gorp/gorp [2] https://github.com/eknkc/amber/ [3] http://www.gorillatoolkit.org/pkg/mux [4] http://www.gorillatoolkit.org/pkg/securecookie

In Six years of Go

cat9·Jun 16, 2015

I've been using go-json-rest, which is by way of "just enough on top of net/http to make APIs easier." https://ant0ine.github.io/go-json-rest/ Gorilla is useful, but more for its range of standalone components than as a framework. https://github.com/gorilla Then you'll want database-related packages like redigo and gorp. https://github.com/garyburd/redigo https://github.com/go-gorp/gorp

In A Comparison of Go Web Frameworks (2014)