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

Feature/closure table custom naming #7120

Merged

Conversation

alexey2baranov
Copy link
Contributor

Description of change

This PR Implements custom naming for closure-table tree.
Closes feature request #7068

Pull-Request Checklist

  • [ + ] Code is up-to-date with the master branch
  • [ + ] npm run lint passes with this change
  • [ + ] npm run test passes with this change
  • [ + ] This pull request links relevant issues as Fixes #0000
  • [ + ] There are new or updated unit tests validating the change
  • [ + ] Documentation has been updated to reflect this change
  • [ + ] The new commits follow conventions explained in CONTRIBUTING.md

Copy link
Contributor

@nebkat nebkat left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Some minor comments there but overall nice change! Make sure you also follow the commit message guidelines. You can squash all of these commits into a single one called feat: Closure table custom naming.

src/decorator/tree/Tree.ts Outdated Show resolved Hide resolved
@@ -32,7 +32,7 @@ export class ClosureJunctionEntityMetadataBuilder {
connection: this.connection,
args: {
target: "",
name: parentClosureEntityMetadata.tableNameWithoutPrefix,
name: parentClosureEntityMetadata.treeOptions && parentClosureEntityMetadata.treeOptions.closureTableName ? parentClosureEntityMetadata.treeOptions.closureTableName : parentClosureEntityMetadata.tableNameWithoutPrefix,
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This and the column names should probably be extracted to a variable since they are very long.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This might not have been the intended change here, see also

this.tableNameWithoutPrefix = namingStrategy.closureJunctionTableName(this.givenTableName!);

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This and the column names should probably be extracted to a variable since they are very long.

Yes, looks very long. Very soon it will be shorten twice and looks good for reading.

parentClosureEntityMetadata?.treeOptions?.ancestorColumnName?.(primaryColumn) || primaryColumn.propertyName + "_ancestor"

What do you think? Maybe we stay it as is to prevent rollback refactor into single command?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This might not have been the intended change here, see also

this.tableNameWithoutPrefix = namingStrategy.closureJunctionTableName(this.givenTableName!);

I prefer to skip NamingStrategy transformation if closureTableName was set explicitly and use transformation if it was not. What do you think?

import {Connection} from "../../../src/connection/Connection";
import {closeTestingConnections, createTestingConnections, reloadTestingDatabases} from "../../utils/test-utils";

describe.only("github issues > #7068", () => {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Probably excessive, to have a copy of all of the old tests.

Just try access the EntityMetadata from connection by filtering for one with the correct name as expected with your configration i.e. "category_xyz_closure". Then check it's columns property to have columns named "ancestor_xyz_" ...

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

IMHO metadata checks doesn't cover real work. One time i saw SubjectExecutor ignores metadata naming. Maybe other parts of code do the same. Are you shure it's good idea to reduce tests?

https://github.com/typeorm/typeorm/blob/master/src/persistence/tree/ClosureSubjectExecutor.ts#L79

Copy link
Contributor Author

@alexey2baranov alexey2baranov left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You can squash all of these commits into a single one called feat: Closure table custom naming.

Yes! I would like to do this. How can I do this?

@@ -32,7 +32,7 @@ export class ClosureJunctionEntityMetadataBuilder {
connection: this.connection,
args: {
target: "",
name: parentClosureEntityMetadata.tableNameWithoutPrefix,
name: parentClosureEntityMetadata.treeOptions && parentClosureEntityMetadata.treeOptions.closureTableName ? parentClosureEntityMetadata.treeOptions.closureTableName : parentClosureEntityMetadata.tableNameWithoutPrefix,
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This and the column names should probably be extracted to a variable since they are very long.

Yes, looks very long. Very soon it will be shorten twice and looks good for reading.

parentClosureEntityMetadata?.treeOptions?.ancestorColumnName?.(primaryColumn) || primaryColumn.propertyName + "_ancestor"

What do you think? Maybe we stay it as is to prevent rollback refactor into single command?

@@ -32,7 +32,7 @@ export class ClosureJunctionEntityMetadataBuilder {
connection: this.connection,
args: {
target: "",
name: parentClosureEntityMetadata.tableNameWithoutPrefix,
name: parentClosureEntityMetadata.treeOptions && parentClosureEntityMetadata.treeOptions.closureTableName ? parentClosureEntityMetadata.treeOptions.closureTableName : parentClosureEntityMetadata.tableNameWithoutPrefix,
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This might not have been the intended change here, see also

this.tableNameWithoutPrefix = namingStrategy.closureJunctionTableName(this.givenTableName!);

I prefer to skip NamingStrategy transformation if closureTableName was set explicitly and use transformation if it was not. What do you think?

@pleerock
Copy link
Member

I think this PR can be merged. Thank you for contributions!

@pleerock pleerock merged commit bcd998b into typeorm:master Jan 12, 2021
zshipleyTAG pushed a commit to Amherst-Development/typeorm that referenced this pull request Oct 7, 2022
* typeorm-0.2.30: (212 commits)
  version bump
  docs: fix javascript usage examples (typeorm#7031)
  fix: resolve migration for UpdateDateColumn without ON UPDATE clause (typeorm#7057)
  fix: Error when sorting by an embedded entity while using join and skip/take (typeorm#7082)
  fix: resolves Postgres sequence identifier length error (typeorm#7115)
  feat: closure table custom naming (typeorm#7120)
  feat: relations: Orphaned row action (typeorm#7105)
  docs: fix invalid code block in "find many options" (typeorm#7268)
  docs: Embodying the example (typeorm#7116)
  docs: document withDeleted option (typeorm#7132)
  fix: return 'null' (instead of 'undefined') on lazy relations that have no results (typeorm#7146) (typeorm#7147)
  docs: update cascade options (typeorm#7140)
  docs: add .ts to supported ormconfig formats (typeorm#7139)
  fix: improve stack traces when using persist executor (typeorm#7218)
  refactor: remove Oracle multirow insert workaround (since typeorm#6927) (typeorm#7083)
  feat: add NOWAIT and SKIP LOCKED lock support for MySQL (typeorm#7236)
  docs: update OneToMany grammar (typeorm#7252)
  feat: JavaScript file migrations output (typeorm#7253)
  docs: update Repository.ts (typeorm#7254)
  chore: update dependency cli-highlight to v2.1.10 (typeorm#7265)
  ...
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants