Skip to content

Conversation

@mightyguava
Copy link
Contributor

JDBC seems to only support positional parameters like ?. I had to write a HACK to convert numbered parameters like $1 to ?. This is buggy and terrible. It also means that you can't use $1 multiple times in the same query to reference the same value.

This is a better change that examines the AST and edits the parser in the parsing step. It's cherry-picked from mightyguava#5 because I'd like to merge changes to core parsing code to master rather than risk complicated merge conflicts later.

When the option is off, nothing changes.

When the option is on, the parameters are no longer sorted by their Number, since we will rely on position as the binding index instead. Repeated parameters are no longer ignored. All parameters are included in the same order they appear in the query string. This means that there may be multiple Columns for the same query with the same Number. The generator can choose to de-dupe or not. Since this option will be tied to the generator, likely only Java/Kotlin generators, this is fine.

parent nodes.Node
rangeVar *nodes.RangeVar
refs map[int]paramRef
refs *[]paramRef
Copy link
Contributor Author

@mightyguava mightyguava Jan 28, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So I tried to make Visit take a pointer receiver: (p *paramSearch), rather than doing a pointer to a slice here. This broke the DeleteVenue query parsing somehow. The parent for the second parameter became a FunctionCall instead of an Expr. I'm a compilers noob so I decided to not dive down that rabbit hole.

EmitJSONTags bool `json:"emit_json_tags"`
EmitPreparedQueries bool `json:"emit_prepared_queries"`
Overrides []Override `json:"overrides"`
// HACK: this is only set in tests, only here till Kotlin support can be merged.
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I promise to remove this when Kolint support is merged :)

@mightyguava
Copy link
Contributor Author

@kyleconroy what do you think about merging this PR? I split it out of the kotlin branch as it's in the parser code and I'm nervous about it running into more merge conflicts (it already has).

@kyleconroy
Copy link
Collaborator

I believe this can be closed now that the Kotlin branch has been merged.

@kyleconroy kyleconroy closed this Feb 12, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants