This defines an implicit conversion from a RootInsertQuery to an InsertQuery, making the INSERT syntax block invisible to the end user.
This defines an implicit conversion from a RootInsertQuery to an InsertQuery, making the INSERT syntax block invisible to the end user. This allows chaining a "value" method call directly after "Table.insert".
The table owning the record.
The record type.
The RootSelectQuery to convert.
An executable SelectQuery.
This defines an implicit conversion from a RootUpdateQuery to an UpdateQuery, making the UPDATE syntax block invisible to the end user.
This defines an implicit conversion from a RootUpdateQuery to an UpdateQuery, making the UPDATE syntax block invisible to the end user. Much like a decision block, a UpdateSyntaxBlock needs a decision branch to follow, may that be nothing, LOW_PRIORITY or IGNORE.
The one catch is that this form of "exit" from an un-executable RootUpdateQuery will directly translate the query to an "UPDATE tableName" query, meaning no UPDATE operators will be used in the default serialisation.
The simple assumption made here is that since the user didn't use any other provided method, such as "lowPriority" or "ignore" the desired behaviour is a full select.
The table owning the record.
The record type.
The RootSelectQuery to convert.
An executable SelectQuery.
This defines an implicit conversion from a RootInsertQuery to an InsertQuery, making the INSERT syntax block invisible to the end user.
This defines an implicit conversion from a RootInsertQuery to an InsertQuery, making the INSERT syntax block invisible to the end user. This allows chaining a "value" method call directly after "Table.insert".
The table owning the record.
The record type.
The RootSelectQuery to convert.
An executable SelectQuery.
This defines an implicit conversion from a RootInsertQuery to an InsertQuery, making the INSERT syntax block invisible to the end user.
This defines an implicit conversion from a RootInsertQuery to an InsertQuery, making the INSERT syntax block invisible to the end user. This is used to automatically "exit" the INSERT syntax block with the default "INSERT INTO" option, while picking no other SQL options such as IGNORE or LOW_PRIORITY.
This is making the following queries equivalent: - Table.insert.into.queryString = "INSERT INTO table" - Table.insert = "INSERT INTO table"
The table owning the record.
The record type.
The RootSelectQuery to convert.
An executable SelectQuery.
This defines an implicit conversion from a RootSelectQuery to a SelectQuery, making the SELECT syntax block invisible to the end user.
This defines an implicit conversion from a RootSelectQuery to a SelectQuery, making the SELECT syntax block invisible to the end user. Much like a decision block, a SelectSyntaxBlock needs a decision branch to follow, may that be DISTINCT, ALL or DISTINCTROW as per the SQL spec.
The one catch is that this form of "exit" from an un-executable RootSelectQuery will directly translate the query to a "SELECT fields* FROM tableName" query, meaning no SELECT operators will be used in the serialisation.
The simple assumption made here is that since the user didn't use any other provided method, such as "all", "distinct" or "distinctrow", the desired behaviour is a full select.
The table owning the record.
The record type.
The RootSelectQuery to convert.
An executable SelectQuery.
This defines an implicit conversion from a RootUpdateQuery to an UpdateQuery, making the UPDATE syntax block invisible to the end user.
This defines an implicit conversion from a RootUpdateQuery to an UpdateQuery, making the UPDATE syntax block invisible to the end user. Much like a decision block, a UpdateSyntaxBlock needs a decision branch to follow, may that be nothing, LOW_PRIORITY or IGNORE.
The one catch is that this form of "exit" from an un-executable RootUpdateQuery will directly translate the query to an "UPDATE tableName" query, meaning no UPDATE operators will be used in the default serialisation.
The simple assumption made here is that since the user didn't use any other provided method, such as "lowPriority" or "ignore" the desired behaviour is a full select.
The table owning the record.
The record type.
The RootSelectQuery to convert.
An executable SelectQuery.
As the implementation of SQL builders may differ depending on the type of SQL database in use, we will provide a series of specific imports for each individual database.
For instance, for MySQL a user will
import com.websudos.morpheus.MySQL.Imports._, for Postgress the user willimport com.websudos.morpheus .Postgres.Imports._and so on. To make our life easy when we reach the point of writing disjoint import objects for the various SQL databases, this trait will provide the base implementation of an "all you can eat" imports object.This includes the various conversions and implicit mechanisms which will have there own underlying structure. As any underlying variable implementation between databases will still extend the same base implementations internally, we can easily override with the settings we need in any place we want.
Thanks to Scala's ability to override the below type aliases, we can easily swap out the base BaseTable implementation for a MySQL specific BaseTable implementation in a manner that's completely invisible to the API user. The naming of things can stay the same while morpheus invisibly implements all necessary discrepancies.