* added PostgreSQL.JSON module
* finished adding all JSON operators
* cleanup
* half way through writing tests
* final tweaks to comments
* finished with JSON tests
* upped persistent dependency to 2.10.0 because of PersistArray data constructor addition needed for JSON operators
* noticed the minus operator with text[] as right operand was only added in PSQL v10, added function and adjusted types/tests
* adjusted yaml configs for updated dependencies and PSQL v10 in Travis
* try to get PostgreSQL 10 running
* use @since notation
* removed postgresql from 'services' field
* and one more time, with FEELING! (and postgresql-10)
* foo
* PSQL 10 runs on 5433, it seems? reverting .travis.yml changes and setting test conn to port 5433
* of course I forget to add the PORT env > .<
* doop-dee-doo
* herp-a-derp
* last commit (hopefully)
* also have more recent dependencies in the 'compiler should error' tests
* why does it feel like this'll go on for a while still?
* copied some extra-deps from the persistent ymls
* aaaaand we're done... right?
* added persistent-postgresql to the dependencies and used its instances for Aeson.Value
* small comment fix
* moved the instances to their own module, this way they're optional to use if you don't use persistent-postgresql
* use port 5432, like a normal PostgreSQL!
* added JSONB newtype with instances, instead of orphaning Aeson.Value
* reworked everything to use the JSONB newtype. And adjusted most comments to reflect the change
* fixed all the tests (just making it compile again)
* that's right, Travis' PSQL v10 NEEEEDS it to be port 5433... for some reason
* update on the haddockumentation
* added JSONAccessor data type for easier usage of certain operators
* Also add to changelog.md
* JSONExpr -> JSONBExpr
* this damn PGPORT is really irritating
Factored out the db specific tests and kept the macros as placeholders.
Import everything in the cabal file for now.
Only using the flags to test that everything still works.
Given that CI only seems to test against GHC 7.10 & GHC 8.0 it's safe to say that only
`base >= 4.8` is officially supported. And empirically, GHC 7.8.4 runs into the compile error below
```
Configuring component lib from esqueleto-2.5.0...
Preprocessing library esqueleto-2.5.0...
[1 of 5] Compiling Database.Esqueleto.Internal.PersistentImport ( src/Database/Esqueleto/Internal/PersistentImport.hs, /tmp/matrix-worker/1485112890/dist-newstyle/build/x86_64-linux/ghc-7.8.4/esqueleto-2.5.0/build/Database/Esqueleto/Internal/PersistentImport.o )
src/Database/Esqueleto/Internal/PersistentImport.hs:7:1: Warning:
The import item ‘PersistQuery(..)’ suggests that
‘PersistQuery’ has (in-scope) constructors or class methods,
but it has none
[2 of 5] Compiling Database.Esqueleto.Internal.Language ( src/Database/Esqueleto/Internal/Language.hs, /tmp/matrix-worker/1485112890/dist-newstyle/build/x86_64-linux/ghc-7.8.4/esqueleto-2.5.0/build/Database/Esqueleto/Internal/Language.o )
src/Database/Esqueleto/Internal/Language.hs:55:1: Warning:
The qualified import of ‘Data.ByteString.Lazy’ is redundant
except perhaps to import instances from ‘Data.ByteString.Lazy’
To import instances alone, use: import Data.ByteString.Lazy()
[3 of 5] Compiling Database.Esqueleto.Internal.Sql ( src/Database/Esqueleto/Internal/Sql.hs, /tmp/matrix-worker/1485112890/dist-newstyle/build/x86_64-linux/ghc-7.8.4/esqueleto-2.5.0/build/Database/Esqueleto/Internal/Sql.o )
src/Database/Esqueleto/Internal/Sql.hs:761:32:
Could not deduce (Functor m1) arising from a use of ‘<$>’
from the context (SqlSelect a r, MonadIO m1, MonadIO m2)
bound by the type signature for
rawSelectSource :: (SqlSelect a r, MonadIO m1, MonadIO m2) =>
Mode -> SqlQuery a -> SqlReadT m1 (Acquire (C.Source m2 r))
at src/Database/Esqueleto/Internal/Sql.hs:(753,20)-(758,57)
or from (SqlBackendCanRead backend)
bound by the type signature for
rawSelectSource :: (SqlBackendCanRead backend) =>
Mode
-> SqlQuery a -> R.ReaderT backend m1 (Acquire (C.Source m2 r))
at src/Database/Esqueleto/Internal/Sql.hs:(759,1)-(778,35)
Possible fix:
add (Functor m1) to the context of
the type signature for
rawSelectSource :: (SqlBackendCanRead backend) =>
Mode
-> SqlQuery a -> R.ReaderT backend m1 (Acquire (C.Source m2 r))
or the type signature for
rawSelectSource :: (SqlSelect a r, MonadIO m1, MonadIO m2) =>
Mode -> SqlQuery a -> SqlReadT m1 (Acquire (C.Source m2 r))
In a stmt of a 'do' block: conn <- persistBackend <$> R.ask
In the expression:
do { conn <- persistBackend <$> R.ask;
res <- run conn;
return $ (C.$= massage) `fmap` res }
In an equation for ‘rawSelectSource’:
rawSelectSource mode query
= do { conn <- persistBackend <$> R.ask;
res <- run conn;
return $ (C.$= massage) `fmap` res }
where
run conn
= uncurry rawQueryRes
$ first builderToText
$ toRawSql mode (conn, initialIdentState) query
massage
= do { mrow <- C.await;
.... }
process = sqlSelectProcessRow
src/Database/Esqueleto/Internal/Sql.hs:882:26:
Could not deduce (Functor m) arising from a use of ‘<$>’
from the context (MonadIO m, SqlSelect a r, IsSqlBackend backend)
bound by the type signature for
rawEsqueleto :: (MonadIO m, SqlSelect a r, IsSqlBackend backend) =>
Mode -> SqlQuery a -> R.ReaderT backend m Int64
at src/Database/Esqueleto/Internal/Sql.hs:(877,17)-(880,39)
Possible fix:
add (Functor m) to the context of
the type signature for
rawEsqueleto :: (MonadIO m, SqlSelect a r, IsSqlBackend backend) =>
Mode -> SqlQuery a -> R.ReaderT backend m Int64
In a stmt of a 'do' block: conn <- persistBackend <$> R.ask
In the expression:
do { conn <- persistBackend <$> R.ask;
uncurry rawExecuteCount
$ first builderToText
$ toRawSql mode (conn, initialIdentState) query }
In an equation for ‘rawEsqueleto’:
rawEsqueleto mode query
= do { conn <- persistBackend <$> R.ask;
uncurry rawExecuteCount
$ first builderToText
$ toRawSql mode (conn, initialIdentState) query }
```
