Since the client factory is a spring data concept, it cannot be
exposed on the configurer. Only expose the cluster and the environment
on it.
This also modifies the config to populate the right beans from the
configurer methods as well.
Since boot needs it for easy mocking/testing, restoring the
configurer (but with the new corresponding beans and only
the subset that is currently available).
Support for positional parameters necessitated caching them, however
that was not done in a threadsafe fashion. ThreadLocal storage is
sufficient to take care of the issue. Added test for it while at it.
After updating the POM to not have a fixed testcontainers version, we
discovered the tests were failing with later versions of testcontainers. It
seems that they updated how they did WaitStrategy, deprecating the old way, so
our WaitStrategy was not being called. That means no setup was done to
the cluster (passwords, buckets, etc...). Simple fix was to move to the
new interface.
There was an integration test which wasn't named properly, and
so it was running with regular tests. This left the container
around, and all subsequent integration tests failed. Simple
fix.
To resolve XSD files properly from the classpath, their HTTPS reference must be present in the spring.schemas to avoid internet interaction for resolving an XSD file.
Plus a test. I didn't notice that Douglas Six did basically the
same thing in another PR (this was a re-do of an earlier PR which
didn't quite do what we'd like). So since I already had it done
and had a test, I closed that PR (#163) and added him to the author
list.
Also - repository.count() raises a NoSuchElementException after you
delete all the documents. That seems like a bug, but we will deal
with that separately.
* add @WithConsistency annotation
* evaluate it and set consistency in AbstractN1qlBasedQuery
* evaluate it and set consistency in ReactiveAbstractN1qlBasedQuery
* add documentation on @WithConsistency
Original pull request: #198.
Seems that LocalDateTime now has microseconds, so the comparison of the unconverted
and converted LocalDateTime will fail, since the conversion/mapping only retains
millisecond precision.
