Support Object Names Greater than 30 Characters for Oracle DB Versions 12.2 and Greater #5197
Conversation
This follows the typical convention used by oracle as all names are always stored in all-uppercase. (names themselves are case insensitive)
This reverts commit d5bc581.
Test DB uses Oracle XE 18, which supports 128 char names.
| const versionParts = oracleVersion | ||
| .split('.') | ||
| .map((versionPart) => parseInt(versionPart)); | ||
| if ( |
There was a problem hiding this comment.
comment explaining the difference would be helpful
There was a problem hiding this comment.
Let me know if the comment I added is in line with what you were thinking @kibertoad
Request from upstream maintainers.
Prevents timing out in the after hook.
|
Just corrected the lint error in the test file I created. Will keep an eye on this for any further feedback since I recently altered the version detection method used in this PR. |
|
Hi there, any idea when this will be included in knex ? thanks in advance. |
I just resolved the merge conflict, but if there are any issues with tests after the merge, I'll have to address those once I am able to finish the current project that demands most of my time at the moment, but other than that, I've addressed all the current feedback from the maintainers, so it depends on when they will take another look at this PR once all tests passing now that I've resolved the merge conflict. |
|
@OlivierCavadenti and @kibertoad I've resolved the merge conflict and it looks like the checks that are failing are the same as those on the current master branch as of when I resolved the merge conflict. Let me know if anything further needs to be done to push this over the finish line. |
|
@Kytech: Perhaps we can get this reviewed again. |
Looks like the maintainers saw your comment, so I take it that they are aware of the current state of this PR. Just waiting to see if any further changes are needed. |
|
@Kytech I'm OK to land the change after conflicts are resolved |
Great! I'll get conflicts resolved within the next hour. |
|
@kibertoad merge conflicts have been resolved. Looks like the CI failures are the same ones as on the master branch - I didn't spot anything new. Let me know if you need me to do anything else to get this wrapped up. |
Since oracle database 12.2, database object names longer than 30 characters has been supported. This PR dynamically sets the maximum character limit for names generated in oracledb based on either the version specified using the
versionattribute in the knex configuration, or it will auto-detect the version number if it is not specified (using a similar technique for auto-detection as is being done in postgres). I added a bit of extra version format processing since oracle version numbers come in both the major.minor format as well as an edition format (such as 9i).Additional unit and integration tests have been added for the new auto-version-detection features as well as the name max length resolution. I have also updated existing integration and unit tests that relied on the hashed names to expect the standard format since the test oracle database is using version 18.
For older oracle versions, the old hashed name method is still used.
One aspect of this change that may or may not need additional consideration is in the scenario that someone using an older knex version, prior to this change, on oracle 12.2 or greater upgrades to the newest version of knex after this feature is released. Knex will no longer try to convert to the hashed name format when performing schema operations. This would be problematic when a "legacy-named" object is altered or deleted in a migration after upgrading. One potential work-around is to set the version manually to
12.1in the knex configuration. The other option is providing a means for renaming the old format to the new format. This may make this a breaking change as it may require configuration changes in some use cases.When running the oracle integration tests, I had several failing, even on master before any of these changes. I have gone through to make sure that all tests that were failing after these changes were the same that were failing before. Unit test results appear to be completing without issue before and after changes.
Closes #3914