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

Edge creation fails because the vertex table name is too long #510

Open
lalicw opened this issue Jun 15, 2024 · 6 comments
Open

Edge creation fails because the vertex table name is too long #510

lalicw opened this issue Jun 15, 2024 · 6 comments
Assignees
Labels

Comments

@lalicw
Copy link

lalicw commented Jun 15, 2024

Version: 3.0
Scenario: If the vertex name length is too long, we cannot create edge.
Cause:When we create edge, we will auto create the in/out vertex reference column like this : schema.table.identifier.__I , schema.table.identifier.__O, if the schema name and table name length is more than max column length, then we failed to create the edge

@pietermartin
Copy link
Owner

I'll check the validation, it should fail to create the schema element if the name is too long as postgres has a 64 char limit on schema element names.

@pietermartin pietermartin self-assigned this Jun 16, 2024
@lalicw
Copy link
Author

lalicw commented Jun 18, 2024

I'll check the validation, it should fail to create the schema element if the name is too long as postgres has a 64 char limit on schema element names.

for example the schema length is 8, and the vertex label length is 60, the vertex identifier name length is 32, if we create edge of this vertex then the in/out vertex reference column like this : schema{length:8}.table{length:60}.identifier{length:32}.__I, the total length is 8+60+32+6 = 106, which exceed the max column length 64.

@pietermartin
Copy link
Owner

Yes, this is a limitation of Sqlg/postgres. The only way to increase the name length is by manually compiling postgres.

However Sqlg should check the size and throw a clear exception, else postgres will silently truncate the name.

@lalicw
Copy link
Author

lalicw commented Jun 18, 2024

Yes, this is a limitation of Sqlg/postgres. The only way to increase the name length is by manually compiling postgres.

However Sqlg should check the size and throw a clear exception, else postgres will silently truncate the name.

mabybe we can auto truncate the column length and then comment the actual name by sql like "comment on column XXX".

@pietermartin
Copy link
Owner

Secretly truncating names is not a good idea as the user will not know what the real (sql) name actually is then. Its best for the user to know the exact name.
Also truncating causes all sorts of problems with duplicates, "aaaaaaaab", "aaaaaaaac" truncating the last char causes duplicates.

For the systems I work on, I tend to make the schema names very short, as they are not too many and the human can remember the shortened schema names.

The system we work on has thousands of tables and millions of properties, so its best if they can remain as close as possible to the domain the users are working on.

@lalicw
Copy link
Author

lalicw commented Jun 18, 2024

Secretly truncating names is not a good idea as the user will not know what the real (sql) name actually is then. Its best for the user to know the exact name. Also truncating causes all sorts of problems with duplicates, "aaaaaaaab", "aaaaaaaac" truncating the last char causes duplicates.

For the systems I work on, I tend to make the schema names very short, as they are not too many and the human can remember the shortened schema names.

The system we work on has thousands of tables and millions of properties, so its best if they can remain as close as possible to the domain the users are working on.

if only for __I and __O column, the truncate result will not be conflict most of the time, and also we can add a nanoId(21 length) as the suffix before __I and __O

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants