Open lukejagodzinski opened 11 months ago
I think the best solution would be to create an md5 hash. The problem is that it would have a dependency on node.
Perhaps we should implement something like some of the answers in this SO question? Like this for example?
Maybe do it only when we detect that string.length() > 50
or something like that.
@dankochetov ?
Does it need to be md5 hash? Could it be just something like table1
, table2
, table3
... whenever a new table name has to be used? I don't think there is a risk of name conflict. I guess query builder doesn't run in parallel?
It can be anything that ensures that the any depth of tables will fit inside the 63 characters. So almost any form of hash or table sequence will work.
I believe that table1
etc. is a better choice that an md5 because it will be easier if people wants to refer to those for some more advanced use cases.
I really need to fix this issue and maybe I can help with it and create some PR. Can you at least point me to the place where the changes should be made?
I was investigating the code and I think the problem is with the relationTableAlias
variable in this method buildRelationalQueryWithoutPK
.
I'm not sure if changing it will break something so I need some guidance. I think it's just that variable that needs trimming/modification. Am I right?
The relational query builder is very complex. This issue needs to be discussed with the team IMO because we need to guarantee uniqueness and repeatability.
Any update update on this issue? Thanks!
Any updates on this issue ??
Any update update on this issue?
Dying for this to be resolved
Any updates? What's the point of a query system if you can't use it?
I really need to fix this issue and maybe I can help with it and create some PR. Can you at least point me to the place where the changes should be made?
I was investigating the code and I think the problem is with the
relationTableAlias
variable in this methodbuildRelationalQueryWithoutPK
.I'm not sure if changing it will break something so I need some guidance. I think it's just that variable that needs trimming/modification. Am I right?
Solved it for now using this solution, just encoding relationTableAlias
and sql.identifier(${tableAlias}_${tsKey})
with MD5, works like a charm.
Don't know if there's any repercussions, patching the package has done the trick.
If the solution is that simple, please include it, one of the reasons I was using Prisma for so long is the relational queries, I would like them working out of the box here!
@jakubczarnowski Can you please give an example how you did it?
@jakubczarnowski Can you please give an example how you did it?
Maybe not how others have done this, but I have implemented a solution which sort of mimic's Django by naming all relations t0
, t1
, etc.
The idea is to store a map of the existing alias (e.g. microcycles_microcycleDays
) to the new alias (e.g. t1
), and each time a new alias is created, the number is incremented.
Feel free to co-opt this, I'm not 100% sure this works yet since I haven't fully tested it but I think it could be worth a shot.
I am curious what the team thinks of @jakubczarnowski 's solution, are there and repercussions to this. If not, would love to see them commit it to the project.
If it's helpful to someone else, I work around the issue with a little helper like this:
/**
* Truncate a constraint name to 63 characters and prepend a provided random
* string to it to make it unique.
*/
function trunkateConstraintName(name: string, id: string) {
const delimiter = "_";
const extension = "_fk";
const end = 63 - id.length - extension.length - delimiter.length;
return id + delimiter + name.slice(0, end) + extension;
}
For the id
param is provide a random 8 char string. Note that this should be a hardcoded random string, not generated at RT.
Any update on this?
I really need to fix this issue and maybe I can help with it and create some PR. Can you at least point me to the place where the changes should be made? I was investigating the code and I think the problem is with the
relationTableAlias
variable in this methodbuildRelationalQueryWithoutPK
. I'm not sure if changing it will break something so I need some guidance. I think it's just that variable that needs trimming/modification. Am I right?Solved it for now using this solution, just encoding
relationTableAlias
andsql.identifier(${tableAlias}_${tsKey})
with MD5, works like a charm. Don't know if there's any repercussions, patching the package has done the trick. If the solution is that simple, please include it, one of the reasons I was using Prisma for so long is the relational queries, I would like them working out of the box here!
How exactly you did this? Can you give a more detailed example, please?
Dying to get this resolved, thank you!
The relational query builder is very complex. This issue needs to be discussed with the team IMO because we need to guarantee uniqueness and repeatability.
@Angelelz Have you had the chance yet to talk to the team? This bug is quite critical for us. Thanks!
Its also very easy to encounter this issue with the auto generated foreign key constraint names.
I guess the drizzle team are shortened table name enjoyers, making everyone rename their fully spelled out tables and fields into 3 -5 letter acronyms
What version of
drizzle-orm
are you using?0.28.6
What version of
drizzle-kit
are you using?0.19.13
Describe the Bug
I have a query using Query API that is doing a lot of nested joins. I've chcecked the generated query and it appears that the generated identifier name is getting truncated because it's too long. From what I read Postgres has a limit of 63-bytes long identifiers. Here is the generated query (I've replaced params with actual values):
And the error says:
Expected behavior
When identifier length is too long it should try to maybe generate acronyms of tables. Instead of
training_step_templates
maybe it should usetst
or maybe even random names to avoid conflicts.Environment & setup
No response