error: exit status 2 about xo HOT 7 CLOSED

The exit status 2 is due to go fmt not processing the generated code correctly (which also means a Go build error). That likely means the schema/query inspection code did not generate all the correct data for your schema. Unfortunately, because of how in the 'pipeline' the schema is inspected, and then code is generated, the SQL right before that error doesn't really indicate anything since the gofmt call is the very last step in the pipeline.

If you could do a go build on the output directory (go build ./outputdir/ ) and copy and paste that error I can try to figure out the issue/cause.

It would be great if I could see the actual schema and try to debug from my end. I'm guessing you don't want to share the schema publicly -- if that's so, feel free to privately email me the schema -- if you can this is -- (my email is [email protected] ) and I can take a look at it and see what's happening.

Again, I really appreciate you testing/using this as the only way to make xo general purpose and robust is to try it against a variety of schemas and databases and brute-force all of these issues. I would really like xo to become a general purpose tool in any Go developer's toolbox that they immediately go to when they are working with schemas (at least for the initial development step), and that can't happen unless xo is being tested in the wild against real world schemas.

from xo.

For the moment, it looks like all the go fmt errors are related to pricing. MySQL describe shows:

| list_price | decimal(10,2) | NO | | 0.00 | |

which results in this line in the resulting .xo.go file:

ListPrice Decimal(10,2) // list_price

The go fmt error is:

product.xo.go:30:19: expected ';', found '('

I hope this helps. Let me know if it doesn't narrow it down and I'll see what I can do with sharing more of the schema. Thanks again for the help and cool library.

from xo.

That's a parsetype issue, and easy to fix, which I'll do in the morning.
Any other Go build errors?
On Feb 28, 2016 9:24 PM, "Willie Abrams" [email protected] wrote:

For the moment, it looks like all the go fmt errors are related to
pricing. MySQL describe shows:

| list_price | decimal(10,2) | NO | | 0.00 | |

which results in this line in the resulting .xo.go file:

ListPrice Decimal(10,2) // list_price

The go fmt error is:

product.xo.go:30:19: expected ';', found '('

I hope this helps. Let me know if it doesn't narrow it down and I'll see
what I can do with sharing more of the schema. Thanks again for the help
and cool library.

—
Reply to this email directly or view it on GitHub
#6 (comment).

from xo.

I just pushed a version that should correctly read the (precision,scale) of numeric/decimal types. Please try and let me know if there are any other issues.

from xo.

go fmt no longer complains. However, I'm not sure if float64 is the right representation for those fields which represent $ in the db.

There is some discussion here: https://forum.golangbridge.org/t/what-is-the-proper-golang-equivalent-to-decimal-when-dealing-with-money/413/7

Doesn't look there are easy answers. (Thanks again for the fixes.)

from xo.

Yes -- we also do not use decimal/numeric in any schemas. Databases are notoriously bad at floating point numbers. If we need to represent floats in a database (why, god, why?) typically we store it as a string and convert / do math in the application. The issue is 1) databases have different internal handling (and its different across platforms/architectures, too!) of floating point numbers, and 2) rarely do you need to do something in a real schema where a query would call for an index on a something like "get all prices below $1.00". That kind of index is better suited and is faster when using integers, so we would put that price in a schema as int with a value of 100.

I had refrained from making an extended comment earlier because you really start getting into philosophical debates (which I want to avoid) when it comes to coding. I am happy to let a developer to choose their own poison, so to speak.

I believe in the long run, the correct way to handle this is to allow on the cli user-specified type mapping. That should not be difficult to implement, but it will have the effect of cluttering / mucking up the relatively clean code base.

To be honest, I would really love a SQL implementation that prevents bad schema design and throws away a lot of the legacy cruft. A lot of these numeric/money/decimal types are reimplemented legacies from the 1980s when the only SQL database you could buy was Oracle, and all the other databases simply implemented support for the same basic data types that Oracle provided, nevermind that Oracle got a lot of the basic designs wrong (ie, '' == null, among others).

from xo.

I hear ya. :-)

No doubt we aren't the only ones who have some some code that follows this pattern, so I'll keep reporting bugs as I work with the xo output so that it can be a more robust tool, regardless of questionable schema choices.

from xo.