misk
misk copied to clipboard
cashapp
Add SQLDelight support
@AlecStrong and I have been adding MySQL support to SQLDelight over the past week, and I think it's just about at the point there's enough functionality to look at getting it in to Misk.
The way I'm picturing this would be to pull the JDBC stuff out in to it's own module, (misk-jdbc?). This would make support config like misk-hibernate does today, and provide a DataSourceService which SQLDelight could use for connections.
Wanted to open this issue to see if a) there's interest in getting this merged. @swankjesse feels like you're the person to ask b) if there is interest, talk next steps for implementing, so there's no surprises in a future PR
High level it'd be good to know if there's more blockers to getting this in misk. We've worked on compatibility with faire's setup and it looks good to go. Schemas can be built from flyway-compatible migration files instead of needing to redeclare anything which I think was the biggest blocker.
The only dependency we need from misk is a DataSource, which we can get from hikari and the existing jdbc setup. It's tied to hibernate but I don't really know if thats an issue.
Actually there is one potential issue, I think Misk currently doesn't support non .SQL extensions for migrations. And I think it might have some issues but having them in resources, but I could be wrong on that.
that should still be fine, the sqldelight task can output .sql files for misk
We've talked about decoupling the jdbc and hibernate stuff internally before to support sqlc and sqldelight. I think people are interested but no one has done the work yet. +1 on separating misk-jdbc and misk-hibernate and I think that's a good first step
The way I'm picturing this would be to pull the JDBC stuff out in to it's own module, (misk-jdbc?). This would make support config like misk-hibernate does today, and provide a DataSourceService which SQLDelight could use for connections.
+1 to extracting JDBC related things
One other point: the Transacter is a really nice abstraction. Unfortunately, if we're talking about code organization, the interface itself includes Hibernate types like Session. Whether we can actually implement that interface or need to write a second one inspired by it, it would be great to preserve some of its ideas, most importantly: demarcating DB transactions with blocks and hiding transaction begin/commit/rollback.
I think the JDBC module should be an implementation detail of actual consumer modules. Really people should only be using something higher level like misk-hibernate which would still have Transacter, or if it's SQLDelight there's a similar Transaction interface for blocking together code in a transaction/providing commit & rollback APIs.
I started working on extracting the pure JDBC parts from Hibernate to separate it into a DataSourceModule (which sets up the Hikari pool and exposes a DataSource) and HibernateModule (which requires a DataSource and exposes a Transacter and a SessionFactory). It's pretty hard because things are quite entangled but I got about half way through. It's been on our agenda for a little while but I don't have time to work on this now. I'd imagine that's the first part of adding non-Hibernate persistence frameworks to misk.
@JGulbronson I'd be happy to review and merge any such PRs though. But start off splitting up the HibernateModule since I know almost nothing about SQLDelight except that it's obviously super awesome. :-)
DataSourceModule which exposes a DataSource would be peeeerfect for SQLDelight, DataSource is the only JDBC dependency needed to initialize everything