FAQ
I've been looking at writing a REST API in Go, and one issue that I ran
into is when I am joining tables to create the Restful resource, often
times we re-use the same resource, in this case "user" for different
meanings.

I'm using the library sqlx, and have structs that map directly to the
Database tables, but then I have a Restful version of that struct that
should be the result of a SQL Join statement and should contain the full
resources references.

Ex:
type Post struct {
   Id int `db:"post_id"`
   Author int `db:"post_author_id"`
   LastUpdater int `db:"post_updater_id"`
}

type User struct {
   Id int `db:"user_id"`
   Name string `db:"user_name"`
}

type RestfulPost struct {
   Post
   Author User
   LastUpdater User
}

In this example, I obviously have some issues with ambiguous column names
which I solve somewhat with struct annotations that sqlx provides and I
alias the columns, however because I embed the User type twice, the
annotations are duplicated, and I feel that adding a Author, and Updater
type that duplicate the columns of User is incorrect.

Should I continue on down this path? Is there a better way to solve this?

Thank you!

--
You received this message because you are subscribed to the Google Groups "golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Search Discussions

  • Daniel Theophanes at Oct 8, 2014 at 3:53 pm
    Doing a restful API per table would imply that you do any joining on the
    client. It would also require you to have a stronger "table" concept on the
    client as well, otherwise the source of the tables becomes muddled and
    table columns as you noted become ambiguous.

    If you want a larger framework and have a medium to large application with
    20+ tables, or want to one off everything and have a small application and
    only have a few tables, this sounds fine.

    Unless you intend to write a very beefy client framework, I'd recommend not
    doing a per table restful API, but rather do a logical action API. Then on
    the server you can automate the simple stuff via your ORM, and drop down
    into whatever query or logic you need for something more complex.

    -Daniel
    On Wednesday, October 8, 2014 6:15:16 AM UTC-7, Jamie Stackhouse wrote:

    I've been looking at writing a REST API in Go, and one issue that I ran
    into is when I am joining tables to create the Restful resource, often
    times we re-use the same resource, in this case "user" for different
    meanings.

    I'm using the library sqlx, and have structs that map directly to the
    Database tables, but then I have a Restful version of that struct that
    should be the result of a SQL Join statement and should contain the full
    resources references.

    Ex:
    type Post struct {
    Id int `db:"post_id"`
    Author int `db:"post_author_id"`
    LastUpdater int `db:"post_updater_id"`
    }

    type User struct {
    Id int `db:"user_id"`
    Name string `db:"user_name"`
    }

    type RestfulPost struct {
    Post
    Author User
    LastUpdater User
    }

    In this example, I obviously have some issues with ambiguous column names
    which I solve somewhat with struct annotations that sqlx provides and I
    alias the columns, however because I embed the User type twice, the
    annotations are duplicated, and I feel that adding a Author, and Updater
    type that duplicate the columns of User is incorrect.

    Should I continue on down this path? Is there a better way to solve this?

    Thank you!
    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Jamie Stackhouse at Oct 8, 2014 at 4:25 pm
    Right on.

    I'm going to move away from sqlx Get/Select methods which auto-populated
    structs as it is just to much work to get it going with joins (pretty much
    every resource we have) and could potentially have duplicate .Columns()
    results.

    Instead, I'm using the more manual method Scan, and populating the
    structure manually. It's a little more typing, but much more explicit, and
    side steps any issues related to column names, however it does imply we
    know the structure of the resulting row (that's a cost I'm ok with).

    Thanks.
    On Wednesday, October 8, 2014 12:53:43 PM UTC-3, Daniel Theophanes wrote:

    Doing a restful API per table would imply that you do any joining on the
    client. It would also require you to have a stronger "table" concept on the
    client as well, otherwise the source of the tables becomes muddled and
    table columns as you noted become ambiguous.

    If you want a larger framework and have a medium to large application with
    20+ tables, or want to one off everything and have a small application and
    only have a few tables, this sounds fine.

    Unless you intend to write a very beefy client framework, I'd recommend
    not doing a per table restful API, but rather do a logical action API. Then
    on the server you can automate the simple stuff via your ORM, and drop down
    into whatever query or logic you need for something more complex.

    -Daniel
    On Wednesday, October 8, 2014 6:15:16 AM UTC-7, Jamie Stackhouse wrote:

    I've been looking at writing a REST API in Go, and one issue that I ran
    into is when I am joining tables to create the Restful resource, often
    times we re-use the same resource, in this case "user" for different
    meanings.

    I'm using the library sqlx, and have structs that map directly to the
    Database tables, but then I have a Restful version of that struct that
    should be the result of a SQL Join statement and should contain the full
    resources references.

    Ex:
    type Post struct {
    Id int `db:"post_id"`
    Author int `db:"post_author_id"`
    LastUpdater int `db:"post_updater_id"`
    }

    type User struct {
    Id int `db:"user_id"`
    Name string `db:"user_name"`
    }

    type RestfulPost struct {
    Post
    Author User
    LastUpdater User
    }

    In this example, I obviously have some issues with ambiguous column names
    which I solve somewhat with struct annotations that sqlx provides and I
    alias the columns, however because I embed the User type twice, the
    annotations are duplicated, and I feel that adding a Author, and Updater
    type that duplicate the columns of User is incorrect.

    Should I continue on down this path? Is there a better way to solve this?

    Thank you!
    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Daniel Theophanes at Oct 8, 2014 at 4:32 pm
    You could skip putting it in structs if you want. Just use a generic buffer
    like:
    http://godoc.org/bitbucket.org/kardianos/table

    Or if you look how that code works, you don't have to codify the DB
    structure in code and could adapt the generic scan to your own use.

    -Daniel

    On Wed, Oct 8, 2014 at 9:25 AM, Jamie Stackhouse wrote:

    Right on.

    I'm going to move away from sqlx Get/Select methods which auto-populated
    structs as it is just to much work to get it going with joins (pretty much
    every resource we have) and could potentially have duplicate .Columns()
    results.

    Instead, I'm using the more manual method Scan, and populating the
    structure manually. It's a little more typing, but much more explicit, and
    side steps any issues related to column names, however it does imply we
    know the structure of the resulting row (that's a cost I'm ok with).

    Thanks.

    On Wednesday, October 8, 2014 12:53:43 PM UTC-3, Daniel Theophanes wrote:

    Doing a restful API per table would imply that you do any joining on the
    client. It would also require you to have a stronger "table" concept on the
    client as well, otherwise the source of the tables becomes muddled and
    table columns as you noted become ambiguous.

    If you want a larger framework and have a medium to large application
    with 20+ tables, or want to one off everything and have a small application
    and only have a few tables, this sounds fine.

    Unless you intend to write a very beefy client framework, I'd recommend
    not doing a per table restful API, but rather do a logical action API. Then
    on the server you can automate the simple stuff via your ORM, and drop down
    into whatever query or logic you need for something more complex.

    -Daniel
    On Wednesday, October 8, 2014 6:15:16 AM UTC-7, Jamie Stackhouse wrote:

    I've been looking at writing a REST API in Go, and one issue that I ran
    into is when I am joining tables to create the Restful resource, often
    times we re-use the same resource, in this case "user" for different
    meanings.

    I'm using the library sqlx, and have structs that map directly to the
    Database tables, but then I have a Restful version of that struct that
    should be the result of a SQL Join statement and should contain the full
    resources references.

    Ex:
    type Post struct {
    Id int `db:"post_id"`
    Author int `db:"post_author_id"`
    LastUpdater int `db:"post_updater_id"`
    }

    type User struct {
    Id int `db:"user_id"`
    Name string `db:"user_name"`
    }

    type RestfulPost struct {
    Post
    Author User
    LastUpdater User
    }

    In this example, I obviously have some issues with ambiguous column
    names which I solve somewhat with struct annotations that sqlx provides and
    I alias the columns, however because I embed the User type twice, the
    annotations are duplicated, and I feel that adding a Author, and Updater
    type that duplicate the columns of User is incorrect.

    Should I continue on down this path? Is there a better way to solve this?

    Thank you!
    --
    You received this message because you are subscribed to a topic in the
    Google Groups "golang-nuts" group.
    To unsubscribe from this topic, visit
    https://groups.google.com/d/topic/golang-nuts/US_F31gP6lE/unsubscribe.
    To unsubscribe from this group and all its topics, send an email to
    golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Andy Balholm at Oct 8, 2014 at 5:22 pm
    If you're using PostgreSQL, you could even let the database generate your JSON for you.

    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupgolang-nuts @
categoriesgo
postedOct 8, '14 at 1:15p
activeOct 8, '14 at 5:22p
posts5
users3
websitegolang.org

People

Translate

site design / logo © 2022 Grokbase