outworkers / sql-parser Goto Github PK

• Add a stage to install ScalaFMT on the Travis CI box using the Debian package installer.
• For this, we simply need to define a .scalafmt file with the configuration.
• Add the sbt validate command as part of the standard pull request runner. This will make the build fail if the formatting of modified code doesn't correspond to standards.

To automatically publish the code to the Central Repository through the existing Outworkers integration, we need to:

• Add the publishSigned command as part of the after_success lifecycle.
• Add the encrypted_key.asc through Travis encrypted files, containing a signing only copy of the master Outworkers PGP key.
• Add the sbt-sonatype plugin to allow publishing to Maven Central automatically.
• Add the sonatypeReleaseAll command after publishing to the intermediary repository.

Before the initial release is made, we need to cover the entire project with comprehensive tests. Make sure the reported code coverage on the few classes that we have is at least 80%.

Steps to complete this ticket:

• Add the sbt-coverage plugin to the build pipeline
• Enable the project with the existing Coveralls integration in Outworkers GitHub.
• Add the sbt-coveralls plugin for Coveralls.io integration.
• Block Pull Requests from being merged to develop branch until code coverage has been reported.
• Add a testWithCoverage command as part of the lifecycle.
• Enable running the testWithCoverage command on a specific Scala version(if building for multiple).

When we bind prepared statements, we need tests and functionality to guarantee a thread safe initialisation. This is because re-preparing statements can cause a performance penalty and can interfere with the low level protocol.

To prevent this, we need a just time initialisation with the appropriate locking and testing, even if the mechanism is as simple as using lazy before every bind definition.

The current problem is that unlike traditional JDBC, the postgres-async driver doesn't seem to return full namespace and prefix metadata for SQL query results. This makes it difficult to parse results such as product.guid vs stockorderitem.guid or to specify the parsers using prefix namespaces at all.

We need a way to define parsers under a namespace, just like anorm allows. Example:

implicit val businessParser: PostgresRowParser[Business] = for {
    id <- get[UUID]("business.guid")
    urn <- get[UUID]("business.guid").map(BusinessURN.apply)
    name <- get[String]("business.name")
  } yield Business(id, urn, name)

Using this parser to extract results from an SQL ResultSet should be equivalent to using a parser definition without a namespace:

implicit val businessParser: PostgresRowParser[Business] = for {
    id <- get[UUID]("guid")
    urn <- get[UUID]("guid").map(BusinessURN.apply)
    name <- get[String]("name")
  } yield Business(id, urn, name)

However, in the case of joins, the parser should rely on the defined metadata to distinguish columns with the same name that belong to different tables. A ResultSet in the case of join can contain columns from multiple tables, and parsers should be able to automatically make use of them.

As we are using the shapeless library throughout the stack, there is no point re-defining basic HList operations using a new ~ operator which does the same thing. Replace the constructs to rely on HLists for tuple flattening and make the existing ~ operator simply be an equivalent of :: on a shapeless.HList.

After we remove the ~ operator we have inherited from Anorm in favour of shapeless.HList, we can successfully remove the entire implementation of Tuple flatteners for the various arities, as they are nothing but Tupler.Aux which already existing in Shapeless, which would allow us to convert an HList to a Tuple using macro derivation hidden away from us, instead of having to write a lot of boilerplat.e