The table owning the record.
The root SQL query to start building from.
The function mapping a row to a record.
This method is used when the query is not returning a data result, such as an UPDATE query.
This method is used when the query is not returning a data result, such as an UPDATE query. While it will accurately monitor the execution of the query and the Future will complete when the task is "done" in SQL, the type-safe mapping of the result is not necessary at this point.
The below implementation will pass type arguments explicitly to the covariant constructor.
The Finagle MySQL client in the scope of which to execute the query.
A Scala Future wrapping a default Finagle MySQL query result object.
This method is used when the query is not returning a data result, such as an UPDATE query.
This method is used when the query is not returning a data result, such as an UPDATE query. While it will accurately monitor the execution of the query and the Future will complete when the task is "done" in SQL, the type-safe mapping of the result is not necessary at this point.
This method duplicates the API to provide an alternative to people who don't use Twitter Futures or any Twitter libraries in their stack. Until now anyway. Twitter has been gossiping about making com.twitter.util.Future extend scala.concurrent.Future, but until such times a dual API is best.
The below implementation will pass type arguments explicitly to the covariant constructor.
The Finagle MySQL client in the scope of which to execute the query.
A Scala Future wrapping a default Finagle MySQL query result object.
The root SQL query to start building from.
A simple forwarding method to prevent some extra boiler-plate during tests.
A simple forwarding method to prevent some extra boiler-plate during tests. This will serialise an existing query to the relevant SQL string.
A string representing the query encoded in SQL.
The function mapping a row to a record.
The table owning the record.
This bit of magic allows all extending sub-classes to implement the "where" and "and" SQL clauses with all the necessary operators, in a type safe way. By providing the third type argument and a custom way to subclass with the predetermined set of arguments, all queries such as UPDATE, DELETE, ALTER and so on can use the same root implementation of clauses and therefore avoid the violation of DRY.
The reason why the "clause" and "andClause" methods below are protected is so that extending classes can decide when and how to expose "where" and "and" SQL methods to the DSL user. Used mainly to make queries like "select.where(_.a = b).where(_.c = d)" impossible, or in other words make illegal programming states unrepresentable. There is an awesome book about how to do this in Scala, I will link to it as soon as the book is published.
The type of the table owning the record.
The type of the record held in the table.