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

Surprising and inconsistent behavior depending on default locale #2672

Open
ScottDugas opened this issue Apr 22, 2024 · 3 comments
Open

Surprising and inconsistent behavior depending on default locale #2672

ScottDugas opened this issue Apr 22, 2024 · 3 comments
Labels
bug Something isn't working test failure A test is failing at least some of the time

Comments

@ScottDugas
Copy link
Contributor

Some of the code in the record layer changes behavior based on the default locale of the system.
Most of this does not seem intentional.

@ScottDugas
Copy link
Contributor Author

One example:

final Optional<LogicalOperator> logicalOperatorOptional = Enums.getIfPresent(LogicalOperator.class, functionName.toUpperCase(Locale.getDefault())).toJavaUtil();

This won't find the enum value with tr_CY

@ScottDugas
Copy link
Contributor Author

ar_BH can cause anything with String.format and %d to result in ? in the string.
For example:

RecordMetaDataBuilderTest > testSetSubspaceKeyCounter() FAILED
    org.opentest4j.AssertionFailedError: expected: <Subspace key counter must be set to a value greater than its current value (3)> but was: <Subspace key counter must be set to a value greater than its current value (?)>
        at app//org.junit.jupiter.api.AssertionUtils.fail(AssertionUtils.java:55)
        at app//org.junit.jupiter.api.AssertionUtils.failNotEqual(AssertionUtils.java:62)
        at app//org.junit.jupiter.api.AssertEquals.assertEquals(AssertEquals.java:182)
        at app//org.junit.jupiter.api.AssertEquals.assertEquals(AssertEquals.java:177)
        at app//org.junit.jupiter.api.Assertions.assertEquals(Assertions.java:1124)
        at app//com.apple.foundationdb.record.metadata.RecordMetaDataBuilderTest.testSetSubspaceKeyCounter(RecordMetaDataBuilderTest.java:594)

I see: https://stackoverflow.com/questions/30049590/string-format-prints-question-mark-as-output

@ScottDugas
Copy link
Contributor Author

Also:

QueryHashTest > collateNoIndex() FAILED
    org.opentest4j.AssertionFailedError: expected: <-1298178617> but was: <1189334216>
        at app//org.junit.jupiter.api.AssertionUtils.fail(AssertionUtils.java:55)
        at app//org.junit.jupiter.api.AssertionUtils.failNotEqual(AssertionUtils.java:62)
        at app//org.junit.jupiter.api.AssertEquals.assertEquals(AssertEquals.java:150)
        at app//org.junit.jupiter.api.AssertEquals.assertEquals(AssertEquals.java:145)
        at app//org.junit.jupiter.api.Assertions.assertEquals(Assertions.java:510)
        at app//com.apple.foundationdb.record.provider.foundationdb.query.QueryHashTest.assertHash(QueryHashTest.java:540)
        at app//com.apple.foundationdb.record.provider.foundationdb.query.QueryHashTest.collateNoIndex(QueryHashTest.java:280)
QueryPlanHashTest > collateNoIndex() FAILED
    org.opentest4j.AssertionFailedError: expected: <-1305756954> but was: <-1304833433>
        at app//org.junit.jupiter.api.AssertionUtils.fail(AssertionUtils.java:55)
        at app//org.junit.jupiter.api.AssertionUtils.failNotEqual(AssertionUtils.java:62)
        at app//org.junit.jupiter.api.AssertEquals.assertEquals(AssertEquals.java:150)
        at app//org.junit.jupiter.api.AssertEquals.assertEquals(AssertEquals.java:145)
        at app//org.junit.jupiter.api.Assertions.assertEquals(Assertions.java:510)
        at app//com.apple.foundationdb.record.provider.foundationdb.query.QueryPlanHashTest.collateNoIndex(QueryPlanHashTest.java:366)

with ro_MD

And:


QueryPlanHashTest > collateNoIndex() FAILED
    org.opentest4j.AssertionFailedError: expected: <-1306680475> but was: <-1320533290>
        at app//org.junit.jupiter.api.AssertionUtils.fail(AssertionUtils.java:55)
        at app//org.junit.jupiter.api.AssertionUtils.failNotEqual(AssertionUtils.java:62)
        at app//org.junit.jupiter.api.AssertEquals.assertEquals(AssertEquals.java:150)
        at app//org.junit.jupiter.api.AssertEquals.assertEquals(AssertEquals.java:145)
        at app//org.junit.jupiter.api.Assertions.assertEquals(Assertions.java:510)
        at app//com.apple.foundationdb.record.provider.foundationdb.query.QueryPlanHashTest.collateNoIndex(QueryPlanHashTest.java:365)

with ko

@ScottDugas ScottDugas added bug Something isn't working test failure A test is failing at least some of the time labels Apr 22, 2024
alecgrieser added a commit to alecgrieser/fdb-record-layer that referenced this issue Apr 24, 2024
…tting for locale

If unspecified, collation `FunctionKeyExpression`s now set their locale to `Locale.ROOT` instead of the machine's default Locale. This makes the contents of index entries more resilient to users changing their machine's default values. This does mean that users who are running with an incompatible locale will need to update their index definitions to reference the appropriate locale or will need to rebuild any indexes that don't already set a locale.

This fixes FoundationDB#2678. This is a specific instance of FoundationDB#2672.
alecgrieser added a commit to alecgrieser/fdb-record-layer that referenced this issue May 8, 2024
…tting for locale

If unspecified, collation `FunctionKeyExpression`s now set their locale to `Locale.ROOT` instead of the machine's default Locale. This makes the contents of index entries more resilient to users changing their machine's default values. This does mean that users who are running with an incompatible locale will need to update their index definitions to reference the appropriate locale or will need to rebuild any indexes that don't already set a locale.

This fixes FoundationDB#2678. This is a specific instance of FoundationDB#2672.
alecgrieser added a commit to alecgrieser/fdb-record-layer that referenced this issue May 8, 2024
…tting for locale

If unspecified, collation `FunctionKeyExpression`s now set their locale to `Locale.ROOT` instead of the machine's default Locale. This makes the contents of index entries more resilient to users changing their machine's default values. This does mean that users who are running with an incompatible locale will need to update their index definitions to reference the appropriate locale or will need to rebuild any indexes that don't already set a locale.

This fixes FoundationDB#2678. This is a specific instance of FoundationDB#2672.
MMcM pushed a commit that referenced this issue May 8, 2024
…cale (#2679)

If unspecified, collation `FunctionKeyExpression`s now set their locale to `Locale.ROOT` instead of the machine's default Locale. This makes the contents of index entries more resilient to users changing their machine's default values. This does mean that users who are running with an incompatible locale will need to update their index definitions to reference the appropriate locale or will need to rebuild any indexes that don't already set a locale.

This fixes #2678. This is a specific instance of #2672.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working test failure A test is failing at least some of the time
Projects
None yet
Development

No branches or pull requests

1 participant