-
Notifications
You must be signed in to change notification settings - Fork 110
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
Rip useless names out of RawDef #1918
base: master
Are you sure you want to change the base?
Conversation
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.
Thanks, LGTM. My only comments would be what's already covered by your TODOs.
I don't understand why it will generate |
Ah, that's because the |
f4f03bb
to
76fd731
Compare
1f37029
to
6a0352e
Compare
crates/bindings-csharp/Codegen.Tests/fixtures/server/snapshots/Module#FFI.verified.cs
Outdated
Show resolved
Hide resolved
71e95df
to
6155764
Compare
I think the remaining test failure here could be related to #1987 so I'm going to work on that first. |
ec275ef
to
0d8145a
Compare
Fix CLI jankily Remove dead comment Implement name generation policy change (private #915 WIP) Update bindings and cli to handle new name format Clippy my nemesis Finish updating csharp module bindings And fix names WIP Placate csharpier Final fixes Fix schema doctests Ah, C# is seeing the autogenerated names despite being on v8 still Add test WIP Previous c# fix could not work due to v8. This one can work until the upgrade Format
7673681
to
ad9593b
Compare
The internal test failures here seem unrelated to what I'm doing, it's a rocksdb compilation failure :/ |
ConstraintRow { constraint_id: 2, table_id: ST_TABLE_ID.into(), unique_columns: col(1), constraint_name: "constraint.unique(st_table,[table_name])", }, | ||
ConstraintRow { constraint_id: 3, table_id: ST_COLUMN_ID.into(), unique_columns: col_list![0, 1], constraint_name: "constraint.unique(st_column,[table_id,col_pos])", }, | ||
ConstraintRow { constraint_id: 4, table_id: ST_SEQUENCE_ID.into(), unique_columns: col(0), constraint_name: "constraint.unique(st_sequence,[sequence_id])", }, | ||
ConstraintRow { constraint_id: 5, table_id: ST_INDEX_ID.into(), unique_columns: col(0), constraint_name: "constraint.unique(st_index,[index_id])", }, | ||
ConstraintRow { constraint_id: 6, table_id: ST_CONSTRAINT_ID.into(), unique_columns: col(0), constraint_name: "constraint.unique(st_constraint,[constraint_id])", }, | ||
ConstraintRow { constraint_id: 7, table_id: ST_CLIENT_ID.into(), unique_columns: col_list![0, 1], constraint_name: "constraint.unique(st_client,[identity,address])", }, | ||
ConstraintRow { constraint_id: 8, table_id: ST_VAR_ID.into(), unique_columns: col(0), constraint_name: "constraint.unique(st_var,[name])", }, | ||
ConstraintRow { constraint_id: 9, table_id: ST_SCHEDULED_ID.into(), unique_columns: col(0), constraint_name: "constraint.unique(st_scheduled,[schedule_id])", }, | ||
ConstraintRow { constraint_id: 10, table_id: ST_SCHEDULED_ID.into(), unique_columns: col(1), constraint_name: "constraint.unique(st_scheduled,[table_id])", }, | ||
ConstraintRow { constraint_id: 11, table_id: ST_ROW_LEVEL_SECURITY_ID.into(), unique_columns: col(1), constraint_name: "constraint.unique(st_row_level_security,[sql])", }, |
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.
Here are examples of the new auto-generated default names in action. (Scroll right.)
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 use the Postgres standard naming scheme: https://stackoverflow.com/a/4108266/1445441
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 is sensitive to name collisions but it's easy to adopt.
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 see comment.
Description of Changes
Addresses #1893
Does NOT address #1891 since the special names turned out to be used throughout the codebase and I think addressing that will require a separate big PR.
While we're reworking naming, we may want to revisit the naming scheme here. It has a problem.
Consider the following declaration:
These indexes will BOTH receive the generated name
"idx_EdgeCase_btree_a_b"
. Weird errors result.(
idx1
andidx2
are now referred to asaccessor_name
s and are stored separately from the name of the index itself.)It would be better if we used out-of-band characters in the index name, like, say,
"EdgeCase.index.btree([a,b])"
. However, if we do this, we will need to relax theIdentifier
validation rules for indexes, since normally those will reject special characters. Also, it means that these identifiers can no longer be used directly as identifiers in SQL. @mamcx, I would welcome your opinion on this. I think it's fine, since system table queries can just wrap names in quotes.We could also use a more elaborate mangling scheme, but this may penalize readability of the system tables.
API and ABI breaking changes
ABI breaking.
Expected complexity level and risk
Reduces complexity overall so let's say 2->1.
Testing
Fixed all relevant tests.