fix: improve operator detection and fix unknown segment #193
Conversation
|
Note that the ci error below seems unrelated to this PR, I don't know anything about @semantic-release/changelog. |
wkeese
force-pushed
the
fix/operator-parsing
branch
from
4a997ab to
820029a
Compare
wkeese
changed the title
wkeese
force-pushed
the
fix/operator-parsing
branch
2 times, most recently
from
0634d9b to
47884ee
Compare
|
This pull request has been marked as stale because it has been open for 14 days with no activity. Remove the stale label or comment or this will be closed in 5 days. |
|
The PR is ready, the build error is an setup problem with github. |
|
This pull request has been marked as stale because it has been open for 14 days with no activity. Remove the stale label or comment or this will be closed in 5 days. |
|
The PR is ready, the build error is an setup problem with github. |
|
This pull request has been marked as stale because it has been open for 14 days with no activity. Remove the stale label or comment or this will be closed in 5 days. |
|
This pull request was closed because it has been stalled for 5 days with no activity. |
|
Hi @wkeese. I'm so sorry for not touching on this and letting the bot harass you. The last few months during which I've neglected maintenance has left this project in a bit of a sorry state. I think the lack of maintenance combined with the unresolved braces CVE in the master branch caused a drop in usage, and now my try to clean up some workflows last week resulted in an accidental 5.0.0 release on NPM which cannot be recalled any longer. This looks good, as it usually does with your code. I'll merge this into beta and ensure it's stable and aim to get a 5.1.0 release out ASAP, since the 5.0.0 isn't stable enough to be called a proper release. As always, thank you. Edit: I'll merge this regardless of the failing Node 14 test as it won't affect the beta branch which drops support for Node 14. |
This fixes the "special" segments to include some missing operators from https://www.w3schools.com/sql/sql_operators.asp and other sites. I took the conservative approach of listing all the operators, as opposed to the general regexp /(?<special>[^\w\s"'`]+)/, because the conservative approach works better in certain cases such as "x>-5". The downside is that you need to list all the operators, so it's a bit fragile, especially since the exact operators vary by SQL version (MySQL, TransactSQL, Postgres, etc.). I kept all the symbols previously specified as "special" even though some of them aren't operators, specifically: , ; : . Fixes scriptcoded#150
Rearrange regexps so "special" regexp catches everything not caught by other regexps. Eliminates the "unknown" segment I added in scriptcoded#148. In practice, the only time we would hit the "unknown" segment is for a few weird characters that weren't already caught by the "special" segment, for example, the ? and unclosed ` in "a `?> b". I figured that in those rare cases, we might as well just call those characters "special". Fixes scriptcoded#178, refs scriptcoded#148.
scriptcoded
force-pushed
the
fix/operator-parsing
branch
from
47884ee to
db31b60
Compare
|
Turns out rebasing the PR fixed the tests as well. |
This fixes the "special" segments to include some missing multi-character operators from https://www.w3schools.com/sql/sql_operators.asp and other sites.
It also expands the "special" segment to match any single character that doesn't match any of the other regexps. That's nice because it gets rid of the need for the "unknown" segment, avoiding the problem listed in #178.
This PR contains two commits that can be merged individually.
Fixes #150, #178, refs #148.