Code generation based type-providers #233
Conversation
|
I'd probably call this "text generation" in order to disambiguate with annotation-based generators that might possibly arrive after annotations become part of Scala. What do you think? |
|
I have the feeling people think of code generation as generating actual source code files. Scala macros on the other hand clearly don't do that. So far we distinguished code-generation based type-providers from macro-based type providers, which seems clear to me. |
| * A meta-model for representing name of column, table, schema and catalog | ||
| */ | ||
| trait Name { | ||
| val name: String |
There was a problem hiding this comment.
because it will be defined once and doesn't need more computation. Why define it as def?
There was a problem hiding this comment.
If there is no reason for using a val here, then using def in the interface and val to implement it in the class seems cleaner to me. IntelliJ seems to warn about it even. See http://stackoverflow.com/questions/7846119/is-there-something-wrong-with-an-abstract-value-used-in-trait-in-scala
|
Seeing all these trees flying around, I wonder why not use quasiquotes. |
|
@cvogt Well, the proposed "text generation" term or "textual code generation", if you will, does highlight this distinction and also has an additional benefit of not leaving room for ambiguities. |
|
@xeno-by Because the decision was not to use quasi-quotes, as it was not in the master branch. |
|
Well now we have reliable ways to get quasiquotes both in 2.10 and in 2.11. Why not refactor? |
| * Qualified name for a meta-model of database | ||
| */ | ||
| case class QualifiedName(parts: List[NamePart]) extends Name { | ||
| override val name = parts.mkString(".") |
There was a problem hiding this comment.
The toString method is used in Java/Scala for user readable representations. I don't think we should used it with different meaning. I suggest parts.map(_.name).mkString(".") instead.
|
Is this still on track to make 2.0? |
|
Yes! It's not going to be part of M3 but it will be in RC1 |
Conflicts: slick-testkit/src/test/scala/scala/slick/test/jdbc/CodeGeneratorTest.scala
| // handles foreign keys | ||
| val fks = mTable.getImportedKeys.list | ||
| val fksGrouped = fks.groupBy(x => | ||
| (QualifiedName(x.pkTable), QualifiedName(x.fkTable))).mapValues(v => { |
There was a problem hiding this comment.
@amirsh why group by pkTable and fkTable not by fkName?
|
closed in favor of #530 |
@amirsh's code-gen based type-providers adapted to work with master (14th Oct 2013). This is not meant to be merged but used for cooperatively reviewing the code.
@cvogt @szeiger