feat(export-to-language): Add Go Support

[prestonvasquez]

Description

GODRIVER-2268

This adds the Go language as an output for the language transpiler, enabling exports for find and aggregation pipelines.

For the dbx-go team, to test on compass locally you can read the instructions for installing here:

1. Install Node ^14.17.5 brew install node@^14.17.5
2. Install npm 7 npm install -g npm7
3. Clone/Fork the compas repository,
4. check out this branch git checkout prestonvasquez:GODRIVER-2268.compassGoExport
5. npm run bootstrap
6. npm run start

Checklist

• New tests and/or benchmarks are included
• Documentation is changed or added

Motivation and Context

• Bugfix
• New feature
• Dependency update
• Misc

Open Questions

There are a few open questions from the dbx-go team:

Q1. Is it possible to do the string parsing within the transpiler code?. This is in reference to how data is transpiled when trying to convert a string to a long type. In its current state the code will generate a function to handle this:

But perhaps it would be better to just cast the literal directly:

bson.D{{ "x": int64("1") }}

Two considerations for casting directly:

1. This code will fail at compile time
2. Including the function adds consistency across other drivers as well as other symbols transpilers within the go driver.

Q2. Are there any cases where the query might contain NumberLong(variable)? This is a follow-up to Q1.

Q3. Also, is it possible to just print an error message, like "unsupported conversion"? This is also a follow-up to Q1. If we are not wanting to include the function in the raw output, should we just not support any raw output that require declarations?

Q4. If we decide to use declarations, do we want them to be functions or variables?

Dependents

This ticket depends on #2964 , which adds the capability of prepending statements with declarations.

Types of changes

• Backport Needed
• Patch (non-breaking change which fixes an issue)
• Minor (non-breaking change which adds functionality)
• Major (fix or feature that would cause existing functionality to change)

[matthewdale]

I noticed the generated code for aggregation pipelines uses a top-level bson.A instead of a mongo.Pipeline. Most of the Go driver documentation shows using a mongo.Pipeline for Aggregate() if all of the pipeline stages are bson.D values (see an example here).

Is it possible to use a mongo.Pipeline instead of a bson.A for the top-level pipeline value in Aggregate() calls?

E.g.

mongo.Pipeline{
    bson.D{{"$sort", bson.D{{"x", 1}}}},
}

[prestonvasquez]

It's almost certainly possible, but at the moment there is no wrapper specifically for aggregations, it just treats [] as whatever our transpiler defines for the ArrayTypeTemplate. Looking at the go-driver aggregation code it seems that bson.A will work in a pinch, but I've created COMPASS-5742 to investigate adding a method to propagate aggregation/filter metadata to the compile methods to create a switch condition to help with this.

[matthewdale]

Sounds reasonable to defer to COMPASS-5742.

[benjirewis]

The Go code looks good to me.

In some examples you ignore the result of a Find or Aggregate operation (I'm assuming because it introduces an unused variable), but it should be pretty obvious to users that they should replace _ with their own variable and continue logic with that variable.

[matthewdale]

Found a few bugs, but everything else looks good!

[matthewdale]

Looks awesome! 👍

[prestonvasquez]

Do we want to wrap all of this in a main() function so that it can be copied and pasted to run without needing to add overhead?

[mcasimir]

other languages don't seem to do that, cc: @mmarcon

[mmarcon]

@mcasimir and I chatted about this. The other languages don't do this but they probably should. A good UX compromise could be to wrap the code inside a function RunAggregation or something like that which then a user can call from their main(). Maybe let's do that as a follow-up PR.