-
-
Notifications
You must be signed in to change notification settings - Fork 499
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
[Entity generator] Overlapping FKs over a column produces first one defined #4898
Comments
boenrobot
pushed a commit
to boenrobot/mikro-orm
that referenced
this issue
Nov 8, 2023
The process of generating relations is heavily altered to output foreign key relations with property names based on the foreign key constrain name, except in cases where the foreign key is the only foreign key involved with a certain column, in which case, that column is used as the name of the property. When composite foreign keys are outputted, all fields are included with "fieldNames". In general, if a metadata property is an array, that array will be outputted correctly. If a column is part of a foreign key (be it a composite one or ambiguous single one), no "plain" column property is generated. Access to the property is through the foreign key properties instead. Fixes mikro-orm#4898.
boenrobot
pushed a commit
to boenrobot/mikro-orm
that referenced
this issue
Nov 8, 2023
The process of generating relations is heavily altered to output foreign key relations with property names based on the foreign key constrain name, except in cases where the foreign key is the only foreign key involved with a certain column, in which case, that column is used as the name of the property. When composite foreign keys are outputted, all fields are included with "fieldNames". In general, if a metadata property is an array, that array will be outputted correctly. If a column is part of a foreign key (be it a composite one or ambiguous single one), no "plain" column property is generated. Access to the property is through the foreign key properties instead. Fixes mikro-orm#4898.
boenrobot
pushed a commit
to boenrobot/mikro-orm
that referenced
this issue
Nov 8, 2023
The process of generating relations is heavily altered to output foreign key relations with property names based on the foreign key constrain name, except in cases where the foreign key is the only foreign key involved with a certain column, in which case, that column is used as the name of the property. When composite foreign keys are outputted, all fields are included with "fieldNames". In general, if a metadata property is an array, that array will be outputted correctly. If a column is part of a foreign key (be it a composite one or ambiguous single one), no "plain" column property is generated. Access to the property is through the foreign key properties instead. Made the order of indexes and FKs explicit, based on the name and definition order of the columns, thus ensuring a consistent output. Fixes mikro-orm#4898.
boenrobot
pushed a commit
to boenrobot/mikro-orm
that referenced
this issue
Nov 8, 2023
The process of generating relations is heavily altered to output foreign key relations with property names based on the foreign key constrain name, except in cases where there is one column that the FK is involved with, in which case, that column is used as the name of the property. When composite foreign keys are outputted, all fields are included with "fieldNames". In general, if a metadata property is an array, that array will be outputted correctly. If a column is part of a foreign key (be it a composite one or ambiguous single one), no "plain" column property is generated, unless all FKs are null-able, while the column is not. Access to the property is through the foreign key properties instead. Made the order of indexes and FKs in the information schema select explicit, based on the name and definition order of the columns, thus ensuring a consistent output. Fixes mikro-orm#4898.
boenrobot
pushed a commit
to boenrobot/mikro-orm
that referenced
this issue
Nov 8, 2023
The process of generating relations is heavily altered to output foreign key relations with property names based on the foreign key constrain name, except in cases where there is one column that the FK is involved with, in which case, that column is used as the name of the property. When composite foreign keys are outputted, all fields are included with "fieldNames". In general, if a metadata property is an array, that array will be outputted correctly. If a column is part of a foreign key (be it a composite one or ambiguous single one), no "plain" column property is generated, unless all FKs are null-able, while the column is not. Access to the property is through the foreign key properties instead. Made the order of indexes and FKs in the information schema select explicit, based on the name and definition order of the columns, thus ensuring a consistent output. Fixes mikro-orm#4898.
boenrobot
pushed a commit
to boenrobot/mikro-orm
that referenced
this issue
Nov 8, 2023
The process of generating relations is heavily altered to output foreign key relations with property names based on the foreign key constrain name, except in cases where there is one column that the FK is involved with, in which case, that column is used as the name of the property. When composite foreign keys are outputted, all fields are included with "fieldNames". In general, if a metadata property is an array, that array will be outputted correctly. If a column is part of a foreign key (be it a composite one or ambiguous single one), no "plain" column property is generated, unless all FKs are null-able, while the column is not. Access to the property is through the foreign key properties instead. Made the order of indexes and FKs in the information schema select explicit, based on the name and definition order of the columns, thus ensuring a consistent output. Fixes mikro-orm#4898.
boenrobot
pushed a commit
to boenrobot/mikro-orm
that referenced
this issue
Nov 8, 2023
The process of generating relations is heavily altered to output foreign key relations with property names based on the foreign key constrain name, except in cases where there is one column that the FK is involved with, in which case, that column is used as the name of the property. When composite foreign keys are outputted, all fields are included with "fieldNames". In general, if a metadata property is an array, that array will be outputted correctly. If a column is part of a foreign key (be it a composite one or ambiguous single one), no "plain" column property is generated, unless all FKs are null-able, while the column is not. Access to the property is through the foreign key properties instead. Made the order of indexes and FKs in the information schema select explicit, based on the name and definition order of the columns, thus ensuring a consistent output. Fixes mikro-orm#4898.
boenrobot
pushed a commit
to boenrobot/mikro-orm
that referenced
this issue
Nov 9, 2023
The process of generating relations is heavily altered to output foreign key relations with property names based on the foreign key constrain name, except in cases where it is safe to use a specific column name instead. When composite foreign keys are outputted, all fields are included with "fieldNames", unless all names involved at the same as the join columns. In general, if a metadata property is an array, that array will be outputted correctly. If a column is part of a foreign key (be it a composite one or ambiguous single one), no "plain" column property is generated, unless all FKs are null-able, while the column is not. Access to the property is through the foreign key properties instead. Made the order of indexes and FKs in the information schema select explicit, based on the name and definition order of the columns, thus ensuring a consistent output. Tweaked the OneToOne relation detection to also work for composite primary keys. If the entire PK is covered by exactly one ManyToOne relation, it now counts at OneToOne regardless of the number of columns involved. Fixes mikro-orm#4898.
boenrobot
pushed a commit
to boenrobot/mikro-orm
that referenced
this issue
Nov 9, 2023
The process of generating relations is heavily altered to output foreign key relations with property names based on the foreign key constrain name, except in cases where it is safe to use a specific column name instead. When composite foreign keys are outputted, all fields are included with "fieldNames", unless all names involved at the same as the join columns. In general, if a metadata property is an array, that array will be outputted correctly. If a column is part of a foreign key (be it a composite one or ambiguous single one), no "plain" column property is generated, unless all FKs are null-able, while the column is not. Access to the property is through the foreign key properties instead. Made the order of indexes and FKs in the information schema select explicit, based on the name and definition order of the columns, thus ensuring a consistent output. Tweaked the OneToOne relation detection to also work for composite primary keys. If the entire PK is covered by exactly one ManyToOne relation, it now counts at OneToOne regardless of the number of columns involved. Fixes mikro-orm#4898.
boenrobot
pushed a commit
to boenrobot/mikro-orm
that referenced
this issue
Nov 9, 2023
The process of generating relations is heavily altered to output foreign key relations with property names based on the foreign key constrain name, except in cases where it is safe to use a specific column name instead. When composite foreign keys are outputted, all fields are included with "fieldNames", unless all names involved at the same as the join columns. In general, if a metadata property is an array, that array will be outputted correctly. If a column is part of a foreign key (be it a composite one or ambiguous single one), no "plain" column property is generated, unless all FKs are null-able, while the column is not. Access to the property is through the foreign key properties instead. Made the order of indexes and FKs in the information schema select explicit, based on the name and definition order of the columns, thus ensuring a consistent output. Tweaked the OneToOne relation detection to also work for composite primary keys. If the entire PK is covered by exactly one ManyToOne relation, it now counts at OneToOne regardless of the number of columns involved. Fixes mikro-orm#4898.
boenrobot
pushed a commit
to boenrobot/mikro-orm
that referenced
this issue
Nov 9, 2023
The process of generating relations is heavily altered to output foreign key relations with property names based on the foreign key constrain name, except in cases where it is safe to use a specific column name instead. When composite foreign keys are outputted, all fields are included with "fieldNames", unless all names involved at the same as the join columns. In general, if a metadata property is an array, that array will be outputted correctly. If a column is part of a foreign key (be it a composite one or ambiguous single one), no "plain" column property is generated, unless all FKs are null-able, while the column is not. Access to the property is through the foreign key properties instead. Made the order of indexes and FKs in the information schema select explicit, based on the name and definition order of the columns, thus ensuring a consistent output. Tweaked the OneToOne relation detection to also work for composite primary keys. If the entire PK is covered by exactly one ManyToOne relation, it now counts at OneToOne regardless of the number of columns involved. Fixes mikro-orm#4898.
boenrobot
pushed a commit
to boenrobot/mikro-orm
that referenced
this issue
Nov 9, 2023
The process of generating relations is heavily altered to output foreign key relations with property names based on the foreign key constrain name, except in cases where it is safe to use a specific column name instead. When composite foreign keys are outputted, all fields are included with "fieldNames", unless all names involved at the same as the join columns. In general, if a metadata property is an array, that array will be outputted correctly. If a column is part of a foreign key (be it a composite one or ambiguous single one), no "plain" column property is generated, unless all FKs are null-able, while the column is not. Access to the property is through the foreign key properties instead. Made the order of indexes and FKs in the information schema select explicit, based on the name and definition order of the columns, thus ensuring a consistent output. Tweaked the OneToOne relation detection to also work for composite primary keys. If the entire PK is covered by exactly one ManyToOne relation, it now counts at OneToOne regardless of the number of columns involved. Fixes mikro-orm#4898.
boenrobot
pushed a commit
to boenrobot/mikro-orm
that referenced
this issue
Nov 13, 2023
The process of generating relations is heavily altered to output foreign key relations with property names based on the foreign key constrain name, except in cases where it is safe to use a specific column name instead. When composite foreign keys are outputted, all fields are included with "fieldNames", unless all names involved at the same as the join columns. In general, if a metadata property is an array, that array will be outputted correctly. If a column is part of a foreign key (be it a composite one or ambiguous single one), no "plain" column property is generated, unless all FKs are null-able, while the column is not. Access to the property is through the foreign key properties instead. Made the order of indexes and FKs in the information schema select explicit, based on the name and definition order of the columns, thus ensuring a consistent output. Tweaked the OneToOne relation detection to also work for composite primary keys. If the entire PK is covered by exactly one ManyToOne relation, it now counts at OneToOne regardless of the number of columns involved. Fixes mikro-orm#4898.
boenrobot
pushed a commit
to boenrobot/mikro-orm
that referenced
this issue
Nov 14, 2023
The process of generating relations is heavily altered to output foreign key relations with property names based on the foreign key constrain name, except in cases where it is safe to use a specific column name instead. When composite foreign keys are outputted, all fields are included with "fieldNames", unless all names involved at the same as the join columns. In general, if a metadata property is an array, that array will be outputted correctly. If a column is part of a foreign key (be it a composite one or ambiguous single one), no "plain" column property is generated, unless all FKs are null-able, while the column is not. Access to the property is through the foreign key properties instead. Made the order of indexes and FKs in the information schema select explicit, based on the name and definition order of the columns, thus ensuring a consistent output. Tweaked the OneToOne relation detection to also work for composite primary keys. If the entire PK is covered by exactly one ManyToOne relation, it now counts at OneToOne regardless of the number of columns involved. Fixes mikro-orm#4898.
boenrobot
pushed a commit
to boenrobot/mikro-orm
that referenced
this issue
Nov 17, 2023
Also moved mikro-orm#4892 into the entity generator folder.
boenrobot
pushed a commit
to boenrobot/mikro-orm
that referenced
this issue
Nov 17, 2023
Also moved mikro-orm#4892 into the entity generator folder.
boenrobot
pushed a commit
to boenrobot/mikro-orm
that referenced
this issue
Nov 20, 2023
Also moved mikro-orm#4892 into the entity generator folder. Moved schema creation in each file into a beforeAll(), rather than at the start of every test.
B4nan
pushed a commit
that referenced
this issue
Nov 20, 2023
As requested in #4898 Co-authored-by: Vasil Rangelov <vasil.tech@condor-gaming.com>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Describe the bug
No pre-existing entities. Trying to generate some from a DB schema.
DB schema has a table where there are two (or more...) FKs, and they include the same column as part of them.
In this case, the shared column gets to be of the type of whichever FK containing that column was defined first, which is not necessarily appropriate.
The times when you'd do this type of thing is when you want the column to comply with multiple constraints, and on application level, this exposes only one of those constraints on the shared column, and the other constraints may or may not be exposed in the other properties.
To Reproduce
Expected behavior
After outputting columns that are only part of one FK (be it single or composite FK), any column that is part of a composite foreign key not already rendered should be outputted as a property with a name based on the foreign key name, rather than the column name. And any column that is covered by composite FKs, all of which are already outputted, should not be outputted at all.
Also, composite foreign keys should feature the full fields involved.
In the case of the above example, this means instead of
the generated output should be
(no productId property; "product_id" featured in "fieldNames" array instead of "fieldName" with only the first field name featured.)
If there was a further 3rd constraint that is only referencing Products, I would expect Sales to have a productId field that is a reference to that, even if that constraint was declared last. However, adding one, but declaring it last, produces the same output as above. Adding it first fixes the type of the productId property, while still keeping the definition of the other ones with incorrect fieldNames.
If there were additional separate constraints on seller_id and country to Sellers and Countries, I would expect the properties to point to those constraints, because those constraints only feature that one column. Then the composite keys would be rendered with property names based on the FK name. Unless a dedicated naming strategy method is introduced, I guess that would mean the properties would be called "fkSalesProductSellers1" and "fkSalesProductCountryMap1".
Additional context
Above example is a simplified reproduction out of a real schema.
Versions
The text was updated successfully, but these errors were encountered: