mirror of
https://github.com/featurebasedb/featurebase.git
synced 2026-08-28 10:54:59 +00:00
b7e9879526
This forward-ports a number of tests from the previous SQL implementation. The porting is approximate in a number of ways, and not all tests are implemented/tested yet. In particular, several tests are currently disabled because we don't support `limit n` constructs. The tests that were primarily tests of the parser have been brought forward as parser tests. One of them has been altered to add parentheses, because our parser interprets fld1 between 1 and 3 and fld2 = 2 as: fld1 between (1 and 3) and (fld2 = 2) which is invalid, while the old parser apparently interpreted it as: (fld1 between 1 and 3) and (fld2 = 2) We have not yet verified the SQL spec's requirements here, but sqlite agrees with our old parser, not our new parser, so this may be a regression. The old tests expected an INNER JOIN to suppress duplicate values. Our new code does not, which is consistent with other SQL implementations. This is a change, but the old behavior appears to have been wrong. (You can still suppress duplicate values by specifying DISTINCT.) In the previous implementations, a value like `count(*)` had `count(*)` as its column name. In the new implementation, it has an empty string as its column name. Related to this, the prior implementation allowed you to write select age, count(*) from grouper group by age having count > 1 but the new implementationt requires that to be spelled as having count(*) > 1 This is consistent with other SQL implementations, so I think the new behavior is correct. The behavior of SHOW COLUMNS and SHOW TABLES has changed, in that the specific results returned are significantly different. Perhaps more significantly, the old system spelled the former query as SHOW FIELDS, rather than SHOW COLUMNS. This may be considered a regression, in that `SHOW FIELDS` no longer works, and we should consider whether any hypothetical users might have been relying on the output of either of these. (I hope not, the new output is much better.) Some of the old tests (the ones in handler_test) were accommodated by adding a couple of specific test cases to existing tests, specifically: * handling timestamp values with `Z` rather than `+00:00` * a join with a WHERE clause referring to fields in both source tables We introduce a new "partial" comparison type, because there's no way for a test of `SHOW TABLES` to contain a correct table row, because `SHOW TABLES` includes timestamps from when tables were created. I'm not sure this is the right way to do this. We add corresponding changes to dax_test, because the DAX tree tests against the SQL tests. We change the returned types of field names and field types to plain strings, ironically because DAX needs this -- the test code in the DAX tree is getting them back as plain strings, rather than as dax.FieldName and dax.BaseType. The tests using `having` are commented out because they don't seem to be working, a ticket has been filed for this. Two of the tests that should return strings are instead returning untranslated integer IDs, but only for DAX, not for the regular SQL tests, and the `delete` test has been commented out for DAX-specific errors. If we merge this, the next step is to ticket those and address them separately. |
||
|---|---|---|
| .. | ||
| boltdb | ||
| computer | ||
| controller | ||
| http | ||
| queryer | ||
| server | ||
| snapshotter | ||
| storage | ||
| test | ||
| writelogger | ||
| address.go | ||
| address_test.go | ||
| controller.go | ||
| dax.go | ||
| directive.go | ||
| docker-compose.yml | ||
| errors.go | ||
| Makefile | ||
| node.go | ||
| README.md | ||
| role.go | ||
| schema.go | ||
| service_manager.go | ||
| snapshot.go | ||
| table.go | ||
| table_test.go | ||
| time.go | ||
| transaction.go | ||
| versioned_partition.go | ||
| versioned_shard.go | ||
| workerjob.go | ||
| workerjob_test.go | ||
DAX
DAX encapsulates anything which covers all of the services which make up the "disaggregation of storage and compute" project. Initially, this will include integration tests which pull in things like Metadata Services (MDS), including the Controller, as well as FeatureBase and IDK-based ingesters.
Setting up the tests
The DAX test currently requires docker images for: featurebase and datagen.
If at any point you run into problems with go mod failing to reference a private
repo, make sure that you have gitlab.com/featurebasedb in your GOPRIVATE
environment variable.
Note that during the docker image build step, go mod vendor is run, which
creates a vendor directory in the root directory, and copies that to docker
during the build stage. Just be aware of this; you may want to remove that
vendor directory after you're done building docker images.
Possible Configuruation
The following were relevent when the dax code was in a separate repository. These may no longer be relevant.
I needed to but this in my ~/.profile file:
export GOPRIVATE=github.com/featurebasedb,gitlab.com/featurebasedb
And this in my ~/.gitconfig
[url "ssh://git@github.com/"]
insteadOf = https://github.com/
[url "ssh://git@gitlab.com/"]
insteadOf = https://gitlab.com/
Then make docker ran successfully.
Build the FeatureBase docker image
- Check out the dax branch of the featurebase repository.
- Run
make docker-image-featurebaseto build the docker image - You should now have an image in docker named
dax/featurebasewith the taglatest.
Build the Datagen docker image
cd <featurebase_repo_root>/idk- Run
make docker-image-datagento build the docker image - You should now have an image in docker named
dax/datagenwith the taglatest.
Running the tests
- Check out the dax branch of the featurebase repository.
- Change into the
daxdirectory:cd dax - Run
make test-integration.