Closed kolemannix closed 11 months ago
Hey, thanks for the report!
The ordering thing is an oversight, will be fixed with #55 .
As for the name collision, there are many ways to fix it. the easiest is to choose a less-likely name for the typeclass instances.
I think I'll let it cook for a while and maybe do something more structured to avoid naming conflicts.
For now it's rather easy to work around if you customize naming. I updated the section now with this exact example
First off, let me say how excited I am to test drive this project! We've got hundreds of tables and over 600 calls to ctx.run, and a mixture of Doobie and Quill throughout the codebase. Our compile times are abysmal, and I'm so excited, looking at the very efficient hand-drived typeclass instances for Doobie, for the compile-time benefits this project may bring us!
Happy to hear it!
I do find it interesting that you're most enthusiastic about the compile-time improvement instead of the prospect of not having to write all that code in the first place 😄
0.4.1 on the way to maven central
I do find it interesting that you're most enthusiastic about the compile-time improvement instead of the prospect of not having to write all that code in the first place
You write it once; you wait for it to compile thousands of times :)
But anyway, our current setup is that we use Flyway to manage the actual schema, writing the schema by hand. We then manually maintain a "Row" case class for each table 🙃 . We then write an insert/get roundtrip test using Doobie's checking functionality against a local DB to ensure we can roundtrip our Row
case classes, doobie also reports any mismatch of the types. Of course I'm excited just to generate the case class from the Schema using Typo, for sure!
Then we're using Quill for what you call "1. CRUD Operations" and "2. Simple Reads" in your docs. We write Doobie queries for 3. Complex Reads and 4. Dynamic Queries. The quill queries are where the vast majority of the compile times come from; we call ctx.run
over 500 times; that's a lot of macro invocations that can also trigger macro invocations!
I am, of course, also excited to try your "SQL files" solution to "3. Complex Reads", but my team's most acute painpoint is compile times!
First off, let me say how excited I am to test drive this project! We've got hundreds of tables and over 600 calls to
ctx.run
, and a mixture of Doobie and Quill throughout the codebase. Our compile times are abysmal, and I'm so excited, looking at the very efficient hand-drived typeclass instances for Doobie, for the compile-time benefits this project may bring us!I have a String Enumeration named
Permission
which is used part of a primary key in another table:The
Ordering[UserPermissionId]
fails to compile becausePermission
has noOrdering
.Additionally (I can file a separate issue if desired), I have a name collision on the local
write
inside thePermission
object.write
is one of the Permissions, as well as the name of the derived doobieWrite
instance. I suppose I could get around this with custom naming? Have not tried yet.