License: Apache Status: Active

Tasks

Done

FIXME

• [ ] Future-based type resolution currently uses a hack to determine 'quietude'. #medium

  At the moment, the default generator forces all types to be found synchronously and then manually calls 'typeMapper.done()'.

• [ ] Remove the override in package.scala to immutable.Seq and just convert in Meta, on the boundary with scala.meta.

TODO

• [ ] Add example code generators and generated projects.

  • [ ] akka-http + quill + Sangria auto-generated GraphQL endpoint (done, needs extracting)
  • [ ] akka-http + quill auto-generated REST endpoint

• [ ] Indirect code generation

  • [ ] Tagged code generation (generate 'object files' and link them later)
  • [ ] On-demand code generation (build a dependency graph of required objects and only build those required)

• [ ] In the default generator, provide a mechanism to override a type by some kind of path.

  e.g. FooTable.BarColumn should be generated with annotation @GraphQLDescription("foobar description")

  The current way to do this would be to write your own class for that type and call typeMapper.found(ColumnName(TableName("FooTable"), "BarColumn"), MyCustomFooBarClass).

• [ ] Incremental code generation Q: wait what? why? this takes 2 seconds to run on hundreds of columns! A: pluggable backends - several of those backends (ElasticSearch, RethinkDB, ...) involve frequent schema evolution. Q: but what's the point of generating Scala code on demand? surely you can't write code against such a moving target? A: well you can if /all/ or /most/ of a project is generated code. moreover you can expose less typesafe shims from the generated code.

Ideas

• [ ] Pluggable backends - back the generator onto other data sources than the database. #v2.x There are much more sophisticated systems than this for this purpose, but a simple tool is a handy tool. Plus few enough use scala.meta.
  • [ ] GraphQL
  • [ ] RethinkDB
  • [ ] ElasticSearch