Closed mkleen closed 1 year ago
retest this please
retest this please
Not perfect, but runs stable and consistent now.
Thinking a bit more about this I'm actually not sure what this covers additionally to the existing RollingUpgradeTest
? That does cover having a mixed version cluster and doing inserts.
The concurrent insert/select aspect is as far as I can tell not that interesting, as it's covered plenty in integration tests in crate/crate, and the mixed version aspect afaik shouldn't have any impact on it.
I thought what we wanted to extend on is the data types used and also use index off
.
Thinking a bit more about this I'm actually not sure what this covers additionally to the existing
RollingUpgradeTest
? That does cover having a mixed version cluster and doing inserts.The concurrent insert/select aspect is as far as I can tell not that interesting, as it's covered plenty in integration tests in crate/crate, and the mixed version aspect afaik shouldn't have any impact on it.
I thought what we wanted to extend on is the data types used and also use
index off
.
I was following https://github.com/crate/crate-qa/issues/271 and I am ok to skip it if it's not useful and redundant.
Thinking a bit more about this I'm actually not sure what this covers additionally to the existing
RollingUpgradeTest
? That does cover having a mixed version cluster and doing inserts. The concurrent insert/select aspect is as far as I can tell not that interesting, as it's covered plenty in integration tests in crate/crate, and the mixed version aspect afaik shouldn't have any impact on it. I thought what we wanted to extend on is the data types used and also useindex off
.I was following #271 and I am ok to skip it if it's not useful and redundant.
I see. I'm not sure what large inserts would additionally cover. Maybe let's put this on hold until Basti is back and we can clarify this. I suspect triggering the recovery logic could be an aspect, but I'm not sure if that's the best way to go about it.
We also recently extended the data type tests in CrateDB to ensure indexers+mapper results in the same fields: https://github.com/crate/crate/blob/9ebfd11a6cf70becf617fe1762bd4a513285ad2d/server/src/testFixtures/java/io/crate/types/DataTypeTestCase.java#L125-L140, so that kind of error scenario would now be covered (at least once we've a test case for each type, which isn't the case yet)
I see. I'm not sure what large inserts would additionally cover. Maybe let's put this on hold until Basti is back and we can clarify this. I suspect triggering the recovery logic could be an aspect, but I'm not sure if that's the best way to go about it.
Sounds good.
Summary of the changes / Why this is an improvement
Resolves https://github.com/crate/crate-qa/issues/271
Checklist