-
Notifications
You must be signed in to change notification settings - Fork 515
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Extract default column adapters to separate module #2121
Extract default column adapters to separate module #2121
Conversation
@@ -0,0 +1,12 @@ | |||
apply plugin: 'org.jetbrains.kotlin.jvm' | |||
|
|||
archivesBaseName = 'sqldelight-primitive-adapters' |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not sure how I feel about the name "primitive" tbh, as Kotlin doesn't have primitive types.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Perhaps we should name it sqldelight-sqlite-adapters
per https://github.com/cashapp/sqldelight/pull/2121/files#r546376383?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yes, given our discussion yesterday the idea is that dialects will have their own repo, and part of it would be a set of adapters - and in this case these are the SQLite adapters, where something like postgres will have none of these since you should be using the correct column type 👍
@@ -0,0 +1,4 @@ | |||
POM_ARTIFACT_ID=primitive-adapters |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'd kinda prefer the name adapters-primitive
as it'd look better when importing dependencies (similar to the Retrofit adapters):
implementation "com.squareup.sqldelight:adapters-primitive:1.4.4"
implementation "com.squareup.sqldelight:adapters-postgresql:1.4.4"
Compared to what we have now:
implementation "com.squareup.sqldelight:primitive-adapters:1.4.4"
implementation "com.squareup.sqldelight:postgresql-adapters:1.4.4"
I went with this approach as we seem to have this style for the other modules (e.g., jdbc-driver
instead of driver-jdbc
)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
whatever works, I think before 2.0 this would become something like "app.cash.sqldelight-sqlite:adapters"
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
or if it stays in this repo "app.cash.sqldelight:sqlite-adapters", where we're doing target first since the target is how we're grouping similar libs
@@ -0,0 +1,9 @@ | |||
package com.squareup.sqldelight.adapter.primitive |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So this probably should be com.squareup.sqldelight.primitive.adapter
if we're following the approach of the other modules (e.g., JdbcDriver
has the import com.squareup.sqldelight.jdbc.driver
), but personally I'd find the grouping in the imports to make a lot more sense here than having the adapter name first.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
similar to above, I'd say keep whatever you've already done and then we can change when we split out the dialects
docs/common/custom_column_types.md
Outdated
## Primitives | ||
|
||
A sibling module that adapts primitives for your convenience. | ||
|
||
```groovy | ||
dependencies { | ||
implementation "com.squareup.sqldelight:primitive-adapters:{{ versions.sqldelight }}" | ||
} | ||
``` | ||
|
||
The following adapters exist: | ||
|
||
- `BooleanColumnAdapter` — Retrieves `kotlin.Boolean` for an SQL type implicitly stored as `kotlin.Long` | ||
- `DoubleColumnAdapter` — Retrieves `kotlin.Double` for an SQL type implicitly stored as `kotlin.Long` | ||
- `FloatColumnAdapter` — Retrieves `kotlin.Float` for an SQL type implicitly stored as `kotlin.Long` | ||
- `IntColumnAdapter` — Retrieves `kotlin.Int` for an SQL type implicitly stored as `kotlin.Long` | ||
- `ShortColumnAdapter` — Retrieves `kotlin.Short` for an SQL type implicitly stored as `kotlin.Long` | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Idk if this should be promoted for use in dialects other than SQLite, as HSQL, MySQL, and PostgreSQL all have native SQL types that map to the above (e.g., in PostgreSQL, a user shouldn't do INT AS kotlin.Short
and use ShortColumnAdapter
as PostgreSQL has the type SMALLINT
which natively decodes to kotlin.Short
). Should this be moved to the SQLite specific documentation (even though it can technically be used by other dialects)?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
SQLite specific
Not too sure why the CI is failing. It looks like an
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
would it be problematic to have these adapters live in runtime
instead of a new module? that's what we currently do for EnumColumnAdapter
@AlecStrong I moved it into a separate module per your comment #2056 (comment) (lmk if I misunderstood it). Also, per #2121 (comment) I'm wondering whether we should promote it for usage in non-SQLite dialects as I'd imagine most other dialects shouldn't need it. Theoretically, most other dialects shouldn't need to use |
resolved comments, once its rebased I'll review all the code. And yea this should all be a separate module assuming that we go down a road where we have
and potentially we just fold adapters into runtime |
@AlecStrong Took a while to fix because of bit rot and some code that was just wrong, but I've updated the PR with the following:
I left the |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
looks great, thank you
@AlecStrong Are these changes available in a release/RC yet? |
no, I was thinking of doing a 2.0 alpha release though - I'll do that later today |
Ok nice. Will it be publicly available? :) |
yep yep it'll be an official release |
Sweet. Thanks. |
So I can just watch out for it here: https://github.com/cashapp/sqldelight/releases ? |
Any thought of when it will be available? 😇 Sorry about the constant questions, but it would be really useful if it's near rc-ready. |
BREAKING CHANGE
These two issues had to be fixed in conjunction, per #2060 (comment).
Closes #2056.
Extracts the default column adapters for
Boolean
,Double
,Float
,Int
, andShort
into a new module named "primitive-adapters".Closes #2060.
Removes the default import in the SQL file for types:
Boolean
,Short
,Int
,Integer
,Long
,Float
,Double
,String
,ByteArray
.