Simple convenience constructor in the case there is a single datasource.
Simple convenience constructor in the case there is a single datasource. Useful in order to not have to construct the datasource over and over again.
When the Jdbc Typer sees a NUMERIC
jdbc column, should it use int/long
instead of BigInteger
if the scale allows?
When the Jdbc Typer sees a NUMERIC
jdbc column, should it use int/long
instead of BigInteger
if the scale allows?
When the Jdbc Typer tries to figure out which Scala/Java objects to use for which JDBC type (e.g.
When the Jdbc Typer tries to figure out which Scala/Java objects to use for which JDBC type (e.g. use String for Varchar(...), Long for bigint etc...), what do we do when we discover a JDBC type which we cannot translate (e.g. blob which is currently not supported by quill). The simplest thing to do is to skip the column.
This generator generates a query schema trait which can be composed with a custom context that you create in your client code (called MySchemaExtensions below because it extends and existing quill context with your query schemas). Here is what that looks like:
A Note on Stereotyping
Stereotyping using the ComposeableTraitsGen is done in the following manner. Firstly, extend a ComposeableTraitsGen and add the Namespacer of your choice. Let's take the
alpha
andbravo
namespaces and combine them into acommon
namespace. Also be sure to set the memberNamer correctly so that the different querySchemas generated won't all be called '.query' in theCommon
object.The following schema should result:
When DAO Objects Collide
Now when you are trying to generate schemas which are not being stereotyped but have equivalent table names for example:
You will not be able to append these two traits to the same quill context because the PersonDao inside alpha and bravo will collide inside of MyCustomContext. Use the parameter
nestedTrait=true
in order to get around this.