I split `HasOrvilleState` to its own file because putting `OrvilleState`
in with the monad things didn't really feel right. Instead I simply put
it directly under `Orville.PostgreSQL`.
Adds ghc-8.10.6 and 8.10.7 as tested compiler versions.
Also updates our nightly check for ghc 9.0.1.
Something of note: a change in the way happy is built means that it
now requires itself to build. This will cause builds to fail for us as
the build tools do not solve for this. To work around it I've included
installing a version of happy from the package manager which allows
the transitive dep of happy to build.
Running the formatter is scripted and depends only on POSIX, `stack`(to install fourmolu), and the `-P` extension to xargs which seems reasonably available and is used to run formatting in parallel.
For example it can run done with `docker-compose run --rm dev sh -c ./scripts/format-repo.sh`.
Some more details:
- Adds a fourmolu configuration file.
- Adds helper script for running the fourmolu during development (that will format all the .hs files found)
- Adds a CI job to check that formatting was done, which can be expanded for more tooling later if desired
- This also uses a helper script, both placed in a orville-postgresql-libpq/scripts directory
- Adds a docker-compose file for running tools in CI and caching the build of them as the build of fourmolu was otherwise taking >2x the runtime of the other jobs
- Runs the formatting on the entire LibPQ codebase.
Adds `OrderByClause` to Expr. This exposes again how easy it is to add new bits of SQL in our current modeling.
But `OrderBy` is, in pure SQL, allowed to have a very wide range of things in it.
To that end this level of abstraction is quite unsafe and potentially invalid SQL is possible.
Creating documentation for the Expr module in general deserves some thought.
The tests have some shared helper functions with the `WhereClause` copied in anticipation of the `Expr` module being broken up and the pieces tested individually.
Left for future work is the handling of NULL first or last, though I suspect that is a relatively straightforward addition.
Also touches up a few minor things:
- Bases off a dockerfile with the latest and greatest stack and debiann
- Adds a stack.yaml file which is a link to the LTS-17.3 specific one
This makes some tooling which looks for a stack.yaml file a bit easier to work with
- Updates the docker-compose.yml to use the stack.yaml file so we can swap the link as desired without changing the compose file.
- Updates the gitignore to ignore TAGS at the top level instead of only in a directory
- Adds a stack-lts-17 config
- Tweaks the docker-compose.yml to use the latest patch of postgresql 9.6
- Updates Dockerfile to base on a version with stack 2.5 instead of the old 1.9
- Adds a very basic circle config that runs the tests
- Adds field definitions for working with Oracle's NUMBER type which can be either Integers or Doubles.
- "Int" columns come back as bytestrings, so a, sadly hacky*, workaround is in place.
- Both "DATE" and "TIMESTAMP" in Oracle correspond to a LocalTime (use with localTimeField).
Perhaps some aliases would be helpful? (eg dateField and/or timestampField pointing to localTimeField)
Notablely some things do not seem to work yet:
- insertRecord fails with "Function sequence error", the statement preparation/execution is a candidate for further investigation
- migrateSchema causes Oracle to spin indefinitely.
There are still some pg specifics to replace (listing constraints/indexes), but avoiding those still causes the CPU to sit at 100% with no end in sight
- selectFirst still has some sql incompatability
* This uses read to get the bytestrings back to ints :( suggestions on better ways to handle this welcome
This creates "orville-postgresql" as a folder containing a library (called "orville-postgresql")
which is home to the previously named "orville" code. It also fixesflipstone/orville#60 in the process.
Follow on work will be to add "orville-oracle" as a sibling to "orville-postgresql".
This script will run compile and run the tests against all the
stack*.yml files that are found in the root of the repo, reporting
whether each one passed or failed.
It is generally useful for doing a final check before pushing, rather
then as the regular edit/compile/test loop to get feedback during
development.
The file would actually be required if anyone were trying to build using cabal
instead of stack. Really should not have been ignored in the first place.
docker-compose will create a volume for stack-root dedicated to orville.
You can add a `docker-compose.override.yml` and override the volume
mounted on `/stack-root` if you want your local development to use an
external volume for `/stack-root`.
