- Notifications
You must be signed in to change notification settings - Fork 4
TestRunnerStatement with dynamic Parameter-list#96
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
Merged
pesse merged 26 commits into develop from feature/testRunnerStatement_as_dynamic_paramListOct 22, 2019
Uh oh!
There was an error while loading. Please reload this page.
Merged
Changes from all commits
Commits
Show all changes
26 commits Select commit Hold shift + click to select a range
de3311c Add some more unit-tests
pesse 7f52a33 completely filled TestRunnerOptions for testing purposes
pesse 156f2d9 Start exploring possibilities for a dynamic TestRunner-Statement
pesse a10b8b7 Merge branch 'develop' into feature/testRunnerStatement_as_dynamic_pa…
pesse 166720b Make getSql public for better testability
pesse 2ce1e79 Test against interface
pesse 6100f3c Slow approach towards new DynamicTestRunner-Statement
pesse 4f591ef Add failing test for Boolean support of DynamicParameterList
pesse 4aba265 Some more params of TestRunner handeled
pesse b3d5779 We can add booleans now
pesse f2e1e01 Two more parameters in the new DynamicStatement
pesse 5ff0ee2 FileMappings are more complicated to pass around
pesse a7b8266 Adding TestFileMappings
pesse e1b7dd3 Implement remaining dynamic parameters
pesse c0ca8cd Remove helper comments
pesse 4afca5f Add version Bugfix-numbers
pesse 32b7d56 Version isGreaterThanOrEqual and isLessOrEqual treat NULL in base ver…
pesse 1b9e0b2 Add tests for all utPLSQL versions
pesse 2a3d9df Added "end case" part
pesse 19a9037 Replace old TestRunnerStatements with the new DynamicTestRunnerStatement
pesse 1751d68 Switch to OpenJDK 8
pesse 02114ae Add utPLSQL 3.1.8 version
pesse 6a0723a Fix Version-String
pesse 3799867 Merge branch 'develop' into feature/testRunnerStatement_as_dynamic_pa…
pesse 6ffa576 Test JDK13 also with version 3.1.8
pesse 97be74d We don't need Maven CFG anymore
pesse File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Uh oh!
There was an error while loading. Please reload this page.
Jump to
Jump to file
Failed to load files.
Loading
Uh oh!
There was an error while loading. Please reload this page.
Diff view
Diff view
There are no files selected for viewing
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters. Learn more about bidirectional Unicode characters
This file was deleted.
Oops, something went wrong.
Uh oh!
There was an error while loading. Please reload this page.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters. Learn more about bidirectional Unicode characters
45 changes: 42 additions & 3 deletions 45 src/main/java/org/utplsql/api/db/DynamicParameterList.java
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters. Learn more about bidirectional Unicode characters
101 changes: 0 additions & 101 deletions 101 src/main/java/org/utplsql/api/testRunner/AbstractTestRunnerStatement.java
This file was deleted.
Oops, something went wrong.
Uh oh!
There was an error while loading. Please reload this page.
Oops, something went wrong.
Uh oh!
There was an error while loading. Please reload this page.
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Don't we need to check
nullMeansEqualhere so that comparetoWithNulls is symmetric?There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sorry, I don't get it...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Shouldn't i2 be treated same way as i1 so that if i2 is null you check nullMeansEqual
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah.
I thought about this a lot yesterday. The thing is - we are not implementing the normal compareTo method, but we implement something which is only used by
isGreaterOrEqualToandisLessOrEqualTo.For these 2 cases I think the comparison order is important, because the lazier "equal" depends on the base version to have a null.
Example:
Technically, when comparing 3.1.7 with 3.1.7.3085, 3.1.7 is less and not equal. That's how the comparison was before (null being treated as 0 basically).
But that's not what I want when using
isGreaterOrEqualTo- I want this function to be forgiving if I only provide 3.1.7 as base, so any number in the 4th level of the comparison should be treated as being equal.On the other hand, when I provide a specific base (e.g. 3.1.7.3085), I really expect it to be precise, so I can't treat i2 the same way in that case.
Maybe I should not use parameters here and instead write the
isGreaterOrEqualTofunction separately so it's more clear we're not implementing a strictcompareTohere.