Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
    Samuel Nelson
    @nelsam
    so I kind of consider gorp to be a project that is "done" for the most part
    hinet
    @hinet
    I want to ignore a field, but I need to join to query the field. What should I do?
    because this only saves the ID in another table in this table, I need the join query name, so the field representing the ID associated name in the structure is ignored.
    hinet
    @hinet
    type Article struct {
        Id         int64 `db:"id, primarykey, autoincrement"`
        Title      string
        CategoryName   string `db:"-" json:"category_name"`
        CategoryId int64  `db:"category_id" json:"category_id"`
    }
    type Category struct{
        Id         int64 `db:"id, primarykey, autoincrement"`
        Name string
    }
    var list []Article
    _,err := Dbm.Select(&list,"select a.*,c.name CategoryName from Article a,Category c where a.category_id = c.id"
    //Query result CategoryName is empty.
    can you help me?
    Samuel Nelson
    @nelsam
    there's a fork of gorp from a while back that might still be in use that solves for this case, but current gorp does not
    can you create an issue on github?
    I don't have a lot of time to spend on gorp, but I can look in to it
    This message was deleted
    Samuel Nelson
    @nelsam
    for now, try falling back to standard sql.Rows logic. something like the following should work:
    type Article struct {
         ID         int64 `db:"id, primarykey, autoincrement"` // ID, not Id; read Effective Go for reasoning
        Title      string
        CategoryID `db:"category_id" json:"-"`
        Category Category `db:"-" json:"category"`
    }
    
    type Category struct{
        ID         int64 `db:"id, primarykey, autoincrement"`
        Name string
    }
    
    // Note: *never* use 'select *' in code.  It makes your code less forward-compatible, which causes
    // a huge mess of issues when you start needing to do rolling deploys.  Among other things.
    rows, err := Dbm.Query("SELECT a.id, a.title, a.category_id, c.id, c.name FROM Article AS a INNER JOIN Category AS c ON a.category_id = c.id")
    if err != nil {
        // handle err
    }
    for rows.Next() {
        var (
            article Article
            cat Category
        )
        rows.Scan(&a.ID, &a.Title, &a.CategoryID, &c.ID, &c.Name)
        // do what you need to with the article and category
    }
    if err := rows.Err(); err != nil {
        // handle err
    }
    hinet
    @hinet
    thanks
    xed
    @xed
    Hi, I try to use sql-migrate for oracle DB(through gorp), and I don`t undestand what I need insert in datasource (dsn connections string), how it looks for oracle?
    Samuel Nelson
    @nelsam
    I have no idea, tbh; but if you're using oracle, you should have some priority support, right?
    they should be able to help you
    Nikesh Pathak
    @nikeshpathak
    Hi , I am trying to create table if not exist using gorp. But it's generating wrong query for Oracle db. Could you please suggest on this
    Samuel Nelson
    @nelsam
    what query is being generated, and what should it be generating?
    you'll probably need to make a PR to update the oracle dialect, here: https://github.com/go-gorp/gorp/blob/master/dialect_oracle.go
    12dollar
    @12dollar
    Hi. Let‘s put a 2021 message here which most probably already answers my question. I have a project based on gorp which I‘m going to pick up again and create a business application out of it. I‘d like an honest opinion if you deem gorp still future-proof or if I should invest some more effort into removing the implementation
    Samuel Nelson
    @nelsam
    I believe that gorp should continue to work for applications which need it, but I think the API is too rigid for long-term maintenance to be viable. previous maintainers and I have tried to come up with a backward-compatibility-breaking design that would be easier to maintain, but the fact is that most of the time, databases are too different for a generic ORM to be useful long-term. I think gorp is fine for getting projects off the ground, but I haven't seen any use case where a generic ORM stays in place past the MVP.
    in my current work, I'm using a code generator to generate queries from migration files, relying on indexed columns to decide which query functions should be generated
    frankly, I don't think I have had a use case where gorp (or, for that matter, gorm) would be viable since about 2015
    @12dollar ^^^
    so long story short: I do make attempts at keeping the project compiling and the tests working, and I try to remember to go through merge requests about once a quarter and merge anything with good test coverage that doesn't change the public API ... but I don't think I'd recommend gorp for new projects
    it doesn't help that the modules tire fire has effectively broken my passion for go as a language
    12dollar
    @12dollar
    Thanks for the fast response @nelsam and being honest about it. This more or less confirms my idea about migrating away from gorp. it's an awesome project, but without active development the chance of having technical debt later on is too big
    Samuel Nelson
    @nelsam

    @12dollar it worked well for its time, but I think active development today would look too different for any current users to bother upgrading. Frankly, I'd rather just build another library, since it'd look so drastically different from what gorp looks like - writing the thing that I have in mind and calling it gorp would be ... disingenuous.

    Whatever you're writing, I have one important piece of (unsolicited ... sorry :) ) advice for you: make sure your project is decoupled from any database libraries (especially database/sql). Use interfaces where you can to decouple; if necessary, make translation wrapper types (e.g. to force (database/sql).Query() to return your local interface type for Rows instead of returning *sql.Rows and forcing your code to heavily couple with database/sql. Frankly, one of the main reasons I don't use or recommend gorp for most new projects is that database/sql is old and crusty and I heavily recommend that people just use github.com/jackc/pgx directly (for postgres).

    12dollar
    @12dollar
    @nelsam : unsolicitated is totally fine ;) thanks for the advice. much appreciated. I currently support mysql and postgres but planned on focussing on postgres alone since I wasn't a fan of mysql anyway (even within enterprise environments). so pgx is totally fine for me and already on my idea list