A few choices:
- If the tables already exist and you only need a subset of up to 22
columns, just leave the other columns out.
- If the tables already exist and you need more than 22 columns for your
queries, do not include all columns in the "*" projection and the
table's type parameter. You can still use all columns in queries as long
as all individual projections contain less than 22 columns. You
shouldn't run into any problems as long as you don't pass a complete
table out of a subquery. This will only pass the columns from * in the
generated SQL code. If you need to pass other columns out of a subquery,
construct an explicit projection.
- Additionally, if you want to create the tables with ScalaQuery,
override AbstractTable.create_* to return an Iterable of all
NamedColumns that should be created. The default implementation of
create_* takes the columns from *. You can also override create_* if
your table contains DBMS-specific special columns like ROWID which are
always present and must not be created explicitly.
-sz
Apparently Slick now has support for nested tuples, but I have not seen a code code example for how to use them with Slick. The second file of this gist (PaypalTransaction.scala) is a partial step towards an example.
https://gist.github.com/4382183
Mike
Here is my latest attempt, complete with error message: https://gist.github.com/4415732
Instead of using nested tuples, I defined two helper classes. Now I have two problems:
- How to define TypeMappers for the helper classes
Considering that this comes up every few weeks, wouldn't it make sense to file an issue against Scala to increase 22 to something larger e. g. 255?
Thanks,
Mike
This is already on the table and we want to look into it for Scala 2.11. Increasing the limit to 255 would add a huge amount of overhead (tuples, products, functions, etc.). What we need is a way to get rid of the limit entirely and allow abstracting over arity without negatively affecting code size or performance (and we already have some ideas how to accomplish that goal).
Stefan,
There are two issues here:
- Your pseudo-code would be much more useful if it were a standalone working code example that left less to the imagination
- A second Slick code example needs to also incorporate a Play form because these two products have yet to be integrated. To see what I mean, look at this posting from the Play mailing list. I will post this message on the Play mailing list so the Play developers are aware also.
This is already on the table and we want to look into it for Scala 2.11. Increasing the limit to 255 would add a huge amount of overhead (tuples, products, functions, etc.). What we need is a way to get rid of the limit entirely and allow abstracting over arity without negatively affecting code size or performance (and we already have some ideas how to accomplish that goal).
That sounds quite interesting. Can you already hint at how you those ideas will work, roughly? Has there been a preliminary publication by the Scala folks about these ideas?
The code I posted compiles and runs. Just add some imports (the obvious ones plus scala.slick.ast.Util._) and a database connection.
--To view this discussion on the web visit https://groups.google.com/d/msgid/scalaquery/76bf53d9-8368-45ef-ae5f-7829a19a4470%40googlegroups.com.
---
You received this message because you are subscribed to the Google Groups "Slick / ScalaQuery" group.
To unsubscribe from this group and stop receiving emails from it, send an email to scalaquery+...@googlegroups.com.
--
To view this discussion on the web visit https://groups.google.com/d/msgid/scalaquery/76bf53d9-8368-45ef-ae5f-7829a19a4470%40googlegroups.com.
---
You received this message because you are subscribed to the Google Groups "Slick / ScalaQuery" group.
To unsubscribe from this group and stop receiving emails from it, send an email to scalaquery+...@googlegroups.com.
Hi,
I am running into this exact same problem. Is there a solution for it?
- Jacob
On Wednesday, November 13, 2013 8:15:36 PM UTC-8, John Ky wrote:Hi Stefan,
Have you got an example for update?
Found this code from Daniel Frei:
case class Person(name: Name, address: Address) case class Name(given: String, family: String) case class Address(street: String, city: String)
def * = (name, address) <> (Person.tupled, Person.unapply) def name = (givenName, familyName) <> (Name.tupled, Name.unapply) def address = (street, city) <> (Address.tupled, Address.unapply)