1. 18
  1.  

  2. 2

    I’ve been using xo/xo for over a year now on my team’s two biggest projects at work. It’s been great – even if the error messaging isn’t super mature. I see little value in using Go for the improved type-safety on Ruby/Python/Node.js just to throw it all with a dynamic ORM layer.

    1. 1

      I had never seen xo/xo. Yea, now I’m confused – looks very similar. At a first glance do you see any obvious differences?

      1. 2

        xo supports more dbs, for one.

        1. 1

          xo/xo isn’t infinitely flexible but you specify the templates to use to generate code for each SQL flavor. We’ve had to heavily augment xo/xo’s default templates since they didn’t provide things like *GetMany or *BulkUpsert. At this point I think the template is definitely more original than default. This in turn meant we had to build our own tooling for list filtering that outputs a squirrel struct. Unfortunately, this layer is dynamic currently because the original version of the code was in Node.js and the API for filtering was just sequelize’s JSON filter objects.

          We haven’t yet gotten into code generation for MySQL but it’s something we’ll be looking into as an optional db backend.

      2. 1

        This looks like it has potential to be really nice. Going to try this out on a WIP right now actually.

        1. 1

          Are you generating Go structures based on the tables schema? How do you handle joins and computed columns?