54dbeec1af
There's a lot going on here. First, we were treating "the test is a Condition" as implying BSI, which it doesn't anymore. Second, the behavior of conditions was weird and BSI-specific. Third, we had to propagate these changes and features throughout a bunch of code, including both the core featurebase code and the DAX replacements/copies of it, plus the SQL3 layer. We refactor this so that tests for equality and inequality work for non-BSI fields, so now if you accidentally use `==` in a Row call on a non-BSI field, it still works; that's not specific to BSI fields anymore. We add a TrackExistence flag to fields, and propagate it through things like our protobuf code, etcetera, so that we can successfully create fields. Newly-created fields get this by default, because we add it unconditionally to them, but the paths that are being called with existing fields don't add it. So, when we "create" (really, just load the definition of) a field from something stored in the schema, we don't add TrackExistence to it, but any path to creating a new field should. A time quantum field with NoStandardView will *effectively* lack TrackExistence. For sets, mutexes, and time quantums with a standard view, anything that sets bits will also set a corresponding bit for the record in a new "existence" view. This allows us to distinguish between an empty set and a null, and also allows null checks to be constant-time. When clearing bits, we don't clear existence bits EXCEPT that if you clear a bit in a mutex, *and the bit actually existed*, we clear the existence bit. For sets and time quantums, clearing bits never clears the existence bit. Deleting records clears the existence bit. We also add code to the `batch` subpackage to generate suitable existence field bitmaps and import them. This logic correctly handles empty sets and nils. The `batch` package does not allow specification of anything equivalent to clearing a single bit from an existing record, so we don't have to deal with the mutex complexity in that case, which is good because it would be impossible. This requires a number of other subtle changes, such as allowing new fields to have more than one FieldOption specified for them. We also drop the handful of implementation bits relating to the "fullySorted" internal-use-only import flag, which existed only to support the JSON ingest API, which we've removed. The most dangerous part of this is that the mutex semantics are impossible to implement on top of our existing API, because they require us to know, not how *many* bits we cleared, but which *specific* bits we cleared. I've implemented this as a new Tx method, which is almost certainly going to be tech debt one day; if we some day drop the Import API, we should remove that. The testing for this is only currently covering the Set/Clear behavior of PQL, and the Import API. The batch tests haven't been written yet. Fields that don't have existence tracking enabled refuse to perform null/not-null tests. They should also report themselves as having no null values -- if a record exists, sets in it are considered empty rather than null. The SQL3 support requires a number of subtle modifications to both featurebase and some addon tooling. The essential thing is dropping the unconditional translation of nil slices to non-nil empty slices in translateResult, both in the executor and the orchestrator. We also modify the logic that handles generating results from Extract calls, to ensure that non-null sets get an empty slice created for them even if they never have any values assigned. The expected results for some tests are different now; we expect to get nil slices, rather than 0-length non-nil slices, for fields which were never written for a given record. Most tests were not changed. (In every case, if a test was failing, I actually checked the logic before changing expected results. This required a lot of tracking down of edge cases.) The batch package now rejects as an error attempts to clear single bits from mutex fields, because so far as I can tell it's simply impossible to have a roaring import that specifies the correct semantics there; you can't tell whether to clear an existence bit without access to the currently-set bits, which the batch API doesn't have. We already supported the special case of specifying a clear value of nil for clearing a mutex field; now that is the only allowed value for a mutex field to have in row.Clears. We change the logic for fixing up incoming view names (in two places) to stop assuming that any view in a time field other than "" that does not have viewStandard as a prefix is a partial time quantum name that should have "standard_" prepended to it. This allows us to submit bitmaps for "existence" to time quantum fields and not have them silently transformed into "standard_existence" because that's what we'd do with "202203". We drop the field ClearBits method, which was totally unused. We drop the sliceDifference function, which was used in a previous mutex implementation and hasn't been used in ages, and the test case for it, and the helper function used only by that test case. |
||
|---|---|---|
| .. | ||
| api | ||
| bankgen | ||
| cmd | ||
| common | ||
| csv | ||
| datagen | ||
| docker-sasl | ||
| fakeidp | ||
| idktest | ||
| internal | ||
| kafka | ||
| kafka_sasl | ||
| kafka_static | ||
| kafkagen | ||
| kinesis | ||
| serverless | ||
| sql | ||
| testdata | ||
| .cloud-env.template | ||
| docker-compose.yml | ||
| Dockerfile | ||
| Dockerfile-fakeIDP | ||
| Dockerfile-test | ||
| Dockerfile-wait | ||
| dup.go | ||
| dup_arm64.go | ||
| file_with_line_delimited_values | ||
| header.go | ||
| header_test.go | ||
| idallocator.go | ||
| idallocator_test.go | ||
| ingest.go | ||
| ingest_test.go | ||
| interfaces.go | ||
| interfaces_test.go | ||
| Makefile | ||
| metrics.go | ||
| pilosa-sec-test.conf | ||
| postgres.go | ||
| progress.go | ||
| README.md | ||
| reingest_test.sh | ||
| sample.csv | ||
| test_postgres.go | ||
| tls.go | ||
| util.go | ||
| util_test.go | ||
| version.go | ||
| wait.sh | ||
idk: Ingest Development Kit
Integration tests
To run the tests, you will need to install the following dependencies:
In addition to these dependancies, you will need to be added to the moleculacorp Dockerhub account.
First start the test environment. This is a docker-compose environment that includes pilosa and a confluent kafka stack. Run the following to start those services:
make startup
To build and run the integration tests, run:
make test-run
An alternative command to use, if you're running tests locally and want human-friendly output, is:
make test-run-local
With that command you can also specify individual tests to run like this:
make test-run-local TCMD='-run=TestJustThisOne .'
Then to shut down the test environment, run:
make shutdown
You can run all of the previous commands by calling test-all:
make test-all
The previous command is equivalent to running the following:
make startup
sleep 30 # wait for services to come up
make test-run
make shutdown
To run an individual test, you can run the command directly using docker-compose. Note that you must run docker-compose build idk-test for docker to run the latest code. Modify the following as needed:
make startup
docker-compose build idk-test
docker-compose run idk-test /usr/local/go/bin/go test -count=1 -mod=vendor -run=TestCmdMainOne ./kafka
To shutdown and reset the environment:
make clean
Running dependencies locally (rather than in docker) "make test-local"
This is for running the tests locally and not in Docker... so you have to be running a bunch of stuff natively on your machine.
Run Pilosa with default config:
pilosa server
Run another pilosa like
pilosa server --config=pilosa-sec-test.conf
which will run Pilosa with TLS using certs in testenv. (make testenv first if you haven't).
You also need to be running the Confluent stack which, after you've installed it from Confluent's site might look something like:
export JAVA_HOME=/Library/Java/JavaVirtualMachines/jdk1.8.0_66.jdk/Contents/Home
confluent local destroy && confluent local start schema-registry
Or it might not! You may not need the first line, but if you have the wrong Java version by default, that's how you set it. The second line may change depending on what version of the confluent stack you get. According to
confluent version
I'm running:
Version: v0.212.0
Git Ref: 2b04985
Use the test-local make target:
make test-local
This sets a number of environment variables (which it prints when you run it), and should set them correctly if you follow the instructions above, but if you're running things on non-default ports you may need to tweak them.
CSV Ingester
- make sure you're running Pilosa (localhost:10101 for these instructions)
molecula-consumer-csv --primary-key-fields=asset_tag -i sample-index --files sample.csv
asset_tag__String,fan_time__RecordTime_2006-01-02,fan_val__String_F_YMD
ABCD,2019-01-02,70%
ABCD,2019-01-03,20%
ABCD,2019-01-04,30%
BEDF,2019-01-02,70%
BEDF,2019-01-05,90%
BEDF,2019-01-08,10%
BEDF,2019-01-08,20%
ABCD,2019-01-30,40%
Datagen
Datagen is an internal command-line tool to generate various application-specific datasets, and ingest them directly into Pilosa. After running make install, run datagen with no arguments to see a list of available "sources".
When running Datagen with local Docker stacks, make sure to add individual docker stacks to the /etc/hosts file:
127.0.0.1 kafka
127.0.0.1 pilosa
127.0.0.1 <docker stack>
ODBC Support
By default, the SQL ingester is not built with ODBC support.
This is because it uses CGO with extra dependencies, and the resulting binaries are not portable.
In order to build with ODBC support, it is necessary to install unixODBC to the system.
Then run:
make bin/molecula-consumer-sql-odbc
Different Linux distros will store certain libraries in different locations. ODBC uses dynamic library loading to handle drivers, so full static linking of dependencies is not possible. It is therefore necessary to build on a system with the same distro and the same software versions as the target machine.