-
Notifications
You must be signed in to change notification settings - Fork 25
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
Support collating sequence for indexed file keys of alphanumeric class #177
Support collating sequence for indexed file keys of alphanumeric class #177
Conversation
2acff2b
to
b33b98e
Compare
108a61b
to
57b4fbc
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
minor changes requested, especially to the test cases and likely to a missing warning
cobc/tree.c
Outdated
@@ -4721,6 +4721,15 @@ validate_indexed_key_field (struct cb_file *f, struct cb_field *records, | |||
} | |||
k = CB_FIELD_PTR (key_ref); | |||
|
|||
/* check collating sequence is not ignored */ | |||
if (f->collating_sequence != NULL && | |||
cbak == NULL && /* only if no alternate key is given (bit of hack for now) */ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why not checking the alternative keys in a loop as well? Aren't the collations used for those?
What about split keys?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Finding a way to avoid emitting "too much" warnings for the file-level collating sequence seems a little tedious here.
Split keys appear to always be handled as alphanumerics (as per the code).
57b4fbc
to
9be8442
Compare
This comment was marked as outdated.
This comment was marked as outdated.
511d25e
to
56e6811
Compare
Looks like this could be merged ; is anything missing here @GitMensch ? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Wondering: don't we need a --without-db
and --with-vbisam
setup in the workflow to verify the tests work as expected in those environments?
Last time I checked VBISAM with 3.x (was a while ago), there were testsuite failures. |
That would be unrelated to a But even with a set of failures (even the NEWS file says that depending on the version of vbisam used there will be some unexpected passes and failures and will do so until we have a V-ISAM version released) this gets "only" down to working it out - we tinker the MSYS2 and MSVC builds for some testsuite expectations in GitHub CI as well - and this does help to catch any new issues that arise (and may also show some positive side effects we otherwise don't catch). |
I'm taking on the "minimal build" and send a PR for that (this should pass here in any case) --> #184 and would let the vbisam part optional to you. |
Sure, but you mentionned |
2a365a5
to
0be00c2
Compare
I think Nicolas took care of all the requested changes ? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Please adjust the testcases, then it is good to go (with the option to add a new warning group and/or national collation "up to libcob" now instead of later)
pos = key_ref; | ||
} | ||
if (colseq != NULL) { | ||
cb_warning_x (COBC_WARN_FILLER, CB_TREE (pos), |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Preferable would be a new warning group -Wignored-something
enabled by default (and add the handful of "ignored" warnings to the same group, but as I currently don't have a clue for a good name and it isn't important this can be done in a follow-up commit :-)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
May ignored-collations
be too precise for this?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That would work but I'd prefer a warning option that we can use for any ignored elements (so yes, too specific ;-)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I see. So that'd be a category like ignored-file-control-clause
or something even more general. I suggest to leave this for a subsequent PR (I won't be available in the very near future to work on that — currently in (pre-)holiday transit, somewhere in Europe ;).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Even more - totally global - so we can include every "ignored" that has no separate warning level (that should be 1 or two warnings currently).
And yes, that's for "sometime in the future".
Before this change, only keys that were alphanumeric elementary items or numeric display were supported.
0be00c2
to
ca1b299
Compare
ca1b299
to
27797e8
Compare
Now upstream. |
Before this change, only keys that were alphanumeric elementary items or numeric display were supported.