Unit tests for operation attempt #1472
Conversation
for #1424, will need tablemetadta on the collectionschema object it was a giant mess, still is, but trying to cleanup gradually
runs, not all unit tests checked Adds OperationAttempt as a base "task" that any operation runs, example in InsertTableOperation and InsertManyCommandResolver No tests written yet.
…TableInsertAttempt
Because there are several ways we create this, the builder is used in the work for OperationAttempt
that is where is is used
added driver profile reset logging to Debug
tweak some error handle and retry because it had issues
amorton
changed the title
| import java.util.HashMap; | ||
| import java.util.Map; | ||
|
|
||
| public class TestData { |
There was a problem hiding this comment.
This could use Javadoc explaining its raison d'etre.
But overall it seems like a complicated abstraction for doing... something.
It seems to me that eager direct construction of XxxTestData classes would work fine and I wonder if this is a solution looking for problem.
There was a problem hiding this comment.
yeah it's still a bit WIP, the idea was to share things like the names so they can be re-used
| try { | ||
| Constructor<?> constructor = clazz.getConstructor(TestData.class); | ||
| return constructor.newInstance(this); | ||
| } catch (NoSuchMethodException |
There was a problem hiding this comment.
just catch (Exception e) and be done?
There was a problem hiding this comment.
will update shortly in another PR to use the wider catch
| } | ||
|
|
||
| @SuppressWarnings("unchecked") | ||
| private <T> T getOrCache(Class<T> clazz) { |
There was a problem hiding this comment.
Does this really make sense over eagerly constructed instances? It's not tons of code but... is there a real performance (or some other) problem being solved?
There was a problem hiding this comment.
the idea was to share the same instances of things, such as the names
amorton
changed the title
What this PR does:
Which issue(s) this PR fixes:
Fixes #
Checklist