Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add query context #22

Merged
merged 4 commits into from
Apr 23, 2024
Merged

Add query context #22

merged 4 commits into from
Apr 23, 2024

Conversation

tsmacdonald
Copy link
Member

Noisy diff since everything is a {:component original-thing, :context [...]} now, but I think the actual semantics of the changes are pretty straighforward.

JSqlParser is inventing some phantom elements (especially JOINs) and I decided it was better to just roll with it for now and let the clients deal with it. Better to have too much info than not enough.

Things were getting hairy so I added a CHANGELOG. Keeping the version numbers correct is a bit of a pain (if a PR merges before this one I'll have to increment the version)

@tsmacdonald tsmacdonald requested a review from a team April 23, 2024 14:04
@tsmacdonald tsmacdonald self-assigned this Apr 23, 2024
Copy link
Contributor

@piranha piranha left a comment

Choose a reason for hiding this comment

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

Except for :component being a long word everything else seems good!

@tsmacdonald tsmacdonald merged commit 1253962 into master Apr 23, 2024
4 checks passed
@tsmacdonald tsmacdonald deleted the parts-of-speech branch April 23, 2024 14:23
Copy link
Contributor

@crisptrutski crisptrutski left a comment

Choose a reason for hiding this comment

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

Please enjoy my post hoc peanut throwing! Looks good overall, but I do wonder whether you won't need to disambiguate which sub-select etc at some stage. We can wait and see I guess, and digging down into the visitedItem for this kind of thing is still possible in the Clojure layer.

Comment on lines +279 to +281
private void pushContext(QueryContext c) {
this.contextStack.push(c.toString());
}
Copy link
Contributor

Choose a reason for hiding this comment

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

Perhaps gilding the lily, but having a withContext(c, f)1 construct instead could protect against any mistake with forgotten or misplaced pops.

Footnotes

  1. An openContext(c) that returns an AutoCloseable to use with a "try with resources" block is another option.

WHERE;

public String toString() {
return name().toUpperCase();
Copy link
Contributor

Choose a reason for hiding this comment

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

nit: A trivial memory optimization is to pre-calculate these strings to a field in a a constructor.

@@ -252,10 +272,19 @@ public void invokeCallback(CallbackKey key, Object visitedItem) {
IFn callback = this.callbacks.get(key);
if (callback != null) {
//noinspection unchecked
this.acc = (Acc) callback.invoke(acc, visitedItem);
this.acc = (Acc) callback.invoke(acc, visitedItem, this.contextStack.toArray());
Copy link
Contributor

Choose a reason for hiding this comment

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

It doesn't seem like you're using the "two headed" nature of the deque, but you're copying twice for each callback (.toArray and then vec). Just using a cons list to avoid (at least) the first copy seems simpler.

On this topic, the order of the contexts in the vector is the opposite of what I'd expect - I'd expect it to go from outside in, roughly reflecting the lexical structure. Is there a practical reason they're listed in the opposite direction?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants