-
Notifications
You must be signed in to change notification settings - Fork 5
Feature/version check #26
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/version check #26
Conversation
Adding orai18n to the dependencies
not sufficient though, we want to have a more specific check with fallback-mechanisms for some features
…PLSQL-java-api into feature/version_check
Also added some tests for getting Framework version and fixed error in getting it
As discussed in slack channel the goal is to have the most actual API version be compatible with the major version of the framework. API of a higher version should always be downwards compatible inside the same major version.
had to restructure current code a bit to support different implementations of TestRunner calls
API should now be able to work for Framework-version 3.0.0 - 3.0.3
…error Close reporters if any unexpected errors occurred while running tests
…into feature/version_check
If check is skipped, the API expects the latest framework version to be present
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.
Some classes are for internal use only and could be hidden from the API users by using the default/protected access modifiers, e.g: the TestRunnerOptions, Version and Statements.
What do you think?
* | ||
* @return | ||
*/ | ||
public String getVersionString() |
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.
Why not override toString?
If it's valid, couldn't you just return the origString?
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.
Agreed with the toString() method.
But I wouldn't return the origString because the class does some normalization, too, e.g. "v3.0.3" will be normalized to "3.0.3" or "version3.0.3" will also be normalized to "3.0.3". With that we are a bit more resilient against little changes.
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.
Actually it might be even better to have the origString as toString-Method and getVersionString renamed to getNormalizedString
- TestRunnerStatement-Implementations are now hidden from public - DatabaseNotCompatibleException now uses Version-objects instead of strings - Version now contains a getNormalizedVersion()-method and it's toString()-method returns the original version string
Included Version-Check with database framework.
If Java-API is not compatible, TestRunner throws a DatabaseNotComptabileException.
Also included a simple Compability solution so API should be usable for 3.0.1, 3.0.2 and 3.0.3