Repository navigation
fix(jdbc): treat non-ASCII characters as identifier characters - #137
Merged
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Fixes #103.
Contract: Hrana 3 is the source of truth for transport, values, metadata, batching, transactions, and error reporting.
java.sqlis the source of truth for the JDBC surface. xerial/sqlite-jdbc is a behavioral reference and conformance foundation, never a copy target.Change
isWordCharinSqlTableReferenceandLibsqlResultSetMetaDatanow treats every character at or above0x80as an identifier character, matching SQLite.SqlTableReference.UNQUOTED_IDENTIFIERaccepts the same range, becauseidentifierOfre-validates word tokens against that pattern; without it the tokenizer would still splitanvändare. ASCII-only behavior is unchanged.Base
aad9c7e456fad5c874e8efdc6f6c2d368244b654, headc47144e6935ed9b145cf2e58eca7dfd39387d526.Red and green
Tests run: 66, Failures: 7(/tmp/xerial-parity-i103/lane-1-regression.log).SqlTableReferenceTest.resolvesNonAsciiTableAndColumngot[null]instead ofanvändare;LibsqlResultSetMetaDataTest.resolvesNonAsciiTableNamegot an empty table name.SqlTableReferenceTest34/34,LibsqlResultSetMetaDataTest32/32, BUILD SUCCESS.Lanes
LibsqlResultSetMetaDataTestgetTableNamereturnsanvändareanvshadow (LibsqlResultSetMetaDataTest, prefix case)användare, notanv./mvnw -pl libsql-jdbc test./mvnw -pl libsql-conformance -am verify./mvnw -pl libsql-conformance -am -Pxerial-control verify./mvnw spotless:check./mvnw test./mvnw -pl libsql-jdbc -am package -DskipTestsPerf:
./mvnw -pl libsql-jdbc testmedians, three interleaved runs per side: trunk 2.08 s, head 2.08 s (within 10%). Logs in/tmp/xerial-parity-i103/.Divergences
UNQUOTED_IDENTIFIERgained the\x80-\uFFFFrange. The plan's Build box names onlyisWordChar, butidentifierOfrejects any word token outside that pattern, so the tokenizer fix alone cannot makeanvändareresolve.LibsqlResultSetMetaDataTestis not in the Files block; lane 2 names it explicitly, so the two metadata cases live there.resolvesQuotedNonAsciiNamesmixes quoted names with an unquoted non-ASCII column, so it fails at trunk as lane 1 requires. The fully quoted assertion (SELECT "namn_ö" FROM "användare") already passed at trunk and is kept as regression coverage only.Tests added: non-ASCII tables, columns, table/column aliases, quoted and bracketed names,
SELECT *expansion, a table namedanvshadowinganvändare, and the metadata path.