conversely, how do we specify if the function returns non-null? (assuming that gets fixed)

That's a great question that I was also pondering. Don't want to introduce any additional non-standard SQL syntax if possible.

id prefer we always return a nullable type for custom functions

anything else you could potentially break

I think it's really more a question of nullability of

CAST

. I could do something like

CAST(NULL AS BLOB)

even without a custom function.

cast should maintain nullability imo

so

CAST(NULL AS BLOB) => ByteArray?

CAST(10 AS BLOB) => BytteArray

I'd be fine with that if it plays out in practice, and then like you said above you pretty much have to assume nullable for custom functions (in the absence of some brand new syntax for declaring their signatures).

I have a little multiplatform example that's using sqldelight 1.0.3 and I just upgraded to 1.1.1. Now within intelliJ I'm getting a dialog that's saying something about "Duplicate content roots detected" and it appears to be removing my common/build/sqldelight/ directory and it's content. As a result I'm getting a bunch of unresolved references to all the classes generated from my tables/sql. I looked through the issues and didn't see anything that matched. Again, this compiles fine with 1.0.3. What am I missing? Thanks for any help.

i believe what you're seeing is https://github.com/square/sqldelight/issues/1260

if you try compilation it should still work, I think its just an issue with the IDE

Unfortunately, it does not compile. My commoncompileKotlinJvm task fails with unresolved references that I mentioned. This is on the command line. I looked at the issue and checked out the project the person who submitted the issue referenced as an example. They have their sqldelight directory under commonMain/ where as I have it under just main/ Is this correct?

what does your gradle look like? you probably need to move them to src/commonMain/sqldelight

That's what I was asking. Where are they supposed to reside? I was going off of the sample here, https://github.com/square/sqldelight/tree/master/sample/common/src but it is still using 1.0.2 Is the location of .sq files dependent on sqldelight version? My sqldelight block looks like this sqldelight { MyDb { packageName = "com.example.foo" sourceFolders = ["src/main/sqldelight"] } } My .sq files are under src/main/sqldelight/com/example/foo

Ah I should uupdate the sample

That would be appreciated. There appears to be enough changed that I'm missing and am not yet following.

you can remove the

sourceFolders =

part of your gradle block and move the .sq files under src/commonMain/sqldelight

theres no way to have the .sq files under src/main anymore for multiplatform

Gotcha, thanks. I looked more at the sample from the submitter of the issue that you referenced and have it compiling now after moving some things around.

Also, the docs here https://github.com/square/sqldelight/blob/master/README.md#gradle kind of suggest that the default is still "src/main/sqldelight" That's what had me convinced I had them in the correct location.

Er, now that I look at it more that's for non-multiplatform. I think I understand now. Thanks again!

Hi guys, I'm trying to use sqldelight on a desktop project. Everything seems to work, except that db is recreated every time I restart the application. On android I don't care about persisting the database somewhere, should I handle this on desktop instead?

Which driver are you using

In my build.gradle I have

implementation 'org.xerial:sqlite-jdbc:3.25.2'
implementation "com.squareup.sqldelight:sqlite-driver:1.1.0"

The JVM driver doesn't really have any support for migrating so you have to do it yourself

That includes checking the version to see if it needs to be recreated

Basically I should check if db exist before using

MyDatabase.Schema.create(driver)

? EDIT: seems like this is not enough... table are erased anyway

@alec on the JVM part of the readme there's this code:

val driver: SqlDriver = JdbcSqliteDriver()
Database.Schema.create(driver)

but if you don't put a name inside the driver the db is "in memory" (or at least that's my conclusion). So using

JdbcSqliteDriver("jdbc:sqlite:mydatabase.db")

will work and persist the db after app restart

Yes that's correct

it would be helpful to add something about this in the readme 🙂