Open milessabin opened 3 years ago
I think we probably need to get the doc site back in shape as well.
Also need to implement subscriptions (in progress).
I'm about to land a second rewrite of the SQL compiler. Now landed.
Low-priority, but it would be cool to cross-build for Scala.js as well. It should be easy since all your dependencies are already on Scala.js with identical APIs, except for doobie. However, the tests would be hampered by the testcontainers
dependency.
Tangential, but IMHO a library cannot really 1.0.0 in the bincompat sense while it has dependencies that themselves have not 1.0.0-ed (in this case, circe, skunk, etc.). The reason is a breaking version bump in one of those dependencies would force a breaking version bump in your library, so you can only be as binary-stable as your least-stable dependency.
Cross-building for Scala.js makes sense ... I'll add it to the list.
Point taken about unstable dependencies. The core module doesn't have any unstable dependencies, so maybe we declare 1.0.0 for core, and have the circe/doobie/skunk module versions track the corresponding upstream versions?
Huh, core also seems to depend on circe, as well as cats-parse.
Hmm ... that could probably be eliminated. It's only used internally, mainly to generate result Json, and it's probably not the most efficient way of doing that, so a faster, stable, alternative might be a better option.
@armanbilge added a couple of issues to reflect your comments: #202, #203.
@armanbilge I think we have to stick with cats-parse. I think on balance I'd be happy to bump Grackle's major version number if we need to update cats-parse before it reaches 1.0.0.
Hi, I'm always looking for open source things to work on and I'd like to help out. Would anyone mind if I worked on #197 or #199? I'm more than happy to look at any other small/self contained issues that might be more useful/appropriate.
@jbotto94 sorry, I missed your message earlier. Both #197 and #199 are real chores and a bit fiddly ... I wouldn't want to inflict them on you. How about #237? It involves digging around in the query algebra and the various places it's used ... I think it'll be a lot more interesting and give more insight into how Grackle hangs together.
@jbotto94 sorry, I missed your message earlier. Both #197 and #199 are real chores and a bit fiddly ... I wouldn't want to inflict them on you. How about #237? It involves digging around in the query algebra and the various places it's used ... I think it'll be a lot more interesting and give more insight into how Grackle hangs together.
Sure :). Wasn't sure if you had started working on it or not.
@milessabin here's another one to add to the list: you should probably replace the log4cats-slf4j dependency with just log4cats-core and ask for a LoggerFactory
constraint. Users can then import an implicit Slf4jLoggerFactory
to satisfy it.
A few motivating reasons:
@armanbilge I think log4cats-slf4j
should only be a test dependency.
@armanbilge apropos SLF4J, see #404.
We're pretty much done! :tada:
I do want to get #258 in as well though.
NoType
(#129)Switch from(#33)NullableType
toNonNullType
Investigate eliminating circe from core(#203)GroupList
from the query algebra (#237)