00ef2380e5
* Formatting adjustments made during code review. While reviewing the BULK INSERT logic (in order to decide how best to approach "ingest via sql" in the cloud), I made a few formatting and comment changes. I'm just adding them here as a separate commit so they don't muddy up my actual work. * Parser modifications to support mulitple tuples in INSERT INTO This commit doesn't include all of the changes required in the planner. Fow now, the planner is simply modified to continue supporting a single tuple (the first tuple in the list). * Update the planner to handle multiple INSERT INTO tuples This is part 1. It's still using the existing logic which builds an ImportRequest for every record (and every field!). The next step will involve using a client.Batch to handle the records. * Introduce client.Importer interface (used by client.Batch) Instead of the Batch having a pointer to a client, this puts an interface there instead (which the client implements). It also allows us to inject a different importer (i.e. other than a featurebase.client) into the Batch. * Decouple batch from client This commit pulls batch-specific code out of the client package and into a new batch package. It introduces the batch.Importer interface, the methods of which replace all the calls that batch was previously making directly to client methods. Finally, it contains two implementations of the batch.Importer interface: one is a wrapper around client, and the other is a wrapper around featurebase.API. * Use docker (instead of MustRunCluster) for internal batch tests Because the `batch` package tests are internal, using test.MustRunCluster() resulted in an import loop (because it eventually imports `server`, and we can't have that). So this commit replaces the use of `test.MustRunCluster()` with docker. The setup is basically the same as that used in the idk docker tests. Here we also remove all client-side references to `UseIngestAPI`, which is an experimental (json) ingest api. It's still suppored on the server, but here we remove the external usage of it. * cherry-pick fix * Use batch.Import() for sql3 INSERT INTO statements * Thread logger into sql3 * fix batch test * Fix some shadowing complaint by linter * Address some test issues related to stringsets * Exclude batch integration tests from CI * Address PR feedback - Added description to batch.README - Consolidated grep commands in .gitlab-ci.yml - Removed some debugging comments - Replaces some inadvertantly removed license headers * Add batch package to gitlab CI * Updated CI for batch package Updated CI include path Update gitlab ci Update CI Update CI Trying new include path for ci Updated gitlab ci include path Made idk race job optional for sonarcloud upload add testdata directory remove testenv from dockercompose file use GIT_STRATEGY clone in batch CI add testdata volume to dockercompose Co-authored-by: Fletcher Haynes <fletcher.haynes@generalassemb.ly> |
||
|---|---|---|
| .. | ||
| api | ||
| bankgen | ||
| cmd | ||
| common | ||
| csv | ||
| datagen | ||
| docker-sasl | ||
| fakeidp | ||
| idktest | ||
| internal | ||
| kafka | ||
| kafka_sasl | ||
| kafka_static | ||
| kafkagen | ||
| kinesis | ||
| 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:
BRANCH_NAME=master make startup
To build and run the integration tests, run:
make test-run
Then to shut down the test environment, run:
make shutdown
You can run all of the previous commands by calling test-all:
BRANCH_NAME=master 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.