ok, got it it! With the help of

find

I see that actually it did create a file, just totally not where I expected it... It's in

~/Library/Application Support/databases/myfile.db

(wtf! 😛).

Hi we are trying out some stuff with the new kotlin version (1.4.0-rc) and we would like to test some of the setup we have, which includes sqlDelight on kotlin/native. Are there going to be releases where the native artefacts are compiled against the new (rc) compiler? Or should we wait until the kotlin plugin itself becomes stable? using the current 1.4.0 sqlDelight gives the incompatible kotlin/native error when using with 1.4.0-rc kotlin.

https://blog.jetbrains.com/kotlin/2020/07/kotlin-1-4-rc-released/

Now that we’ve reached the final release candidate for Kotlin 1.4, it is time for you to start compiling and publishing! Unlike previous milestone releases, binaries created with Kotlin 1.4.0-RC are guaranteed to be compatible with Kotlin 1.4.0.

nice

i'm not super enthusiastic about having a release version depend on an RC

anyway, here's a tracking issue: https://github.com/cashapp/sqldelight/issues/1859

Will need SQLiter release in addition to Stately

I’m using

wire-schema

to do some manipulation of proto files in memory. Is there anyway to add a

ProtoFile

directly to the

SchemaLoader

to resolve links? Trying to add ProtoFiles that I create myself to the set.

don't think so. i'm doing some work in this area. feel free to file a bug with your use case.

I think

Schema.fromFiles

does this actually

But schemas themselves are effectively immutable.

they are, yes. i'm making the ProtoFile and eveything beneath it have public constructors so that you can manipulate them in memory and then use

Schema.fromFiles

to link everything

Yeah that works. My use case here is taking a proprietary pseudo-flatbuffer format--I have an antlr grammar for it fortunately--and convert them into protobuf files

Oh no, I just realized ProtoFile has private constructor. Jake you’re using

ProtoFileElement

then converting that to a

ProtoFile

via the companion function right?

i'm taking a ProtoFile and want to produce another ProtoFile. The elements are not public API.

Alright I did open an issue asking essentially to make the Element types mutable, which would also involve making them public. I suppose there might be a better way, but it looks like right now you do need to use

toElement

then do a bunch of

copy

calls. If you want to mutate in-place it doesn’t seem possible.

Why does the wire-schema library depend on wire-runtime?

it can create a ProtoAdapter on-the-fly for the ability to parse self-describing messages

Ah interesting, makes sense

I'm struggling to include the sqldelight coroutine extensions in a multiplatform project. I think I have a minimal project reproducing the error here:

buildscript {
    repositories {
        google()
        mavenCentral()
    }
    dependencies {
        classpath 'com.squareup.sqldelight:gradle-plugin:1.4.0'
    }
}

plugins {
    id 'org.jetbrains.kotlin.multiplatform' version '1.3.72'
    id('com.squareup.sqldelight') version '1.4.0'
}

repositories {
    google()
    mavenCentral()
}

kotlin {

    jvm()
    mingwX64("mingw")

    sourceSets {
        commonMain {
            dependencies {
                implementation kotlin('stdlib-common')
                implementation "org.jetbrains.kotlinx:kotlinx-coroutines-core-common:1.3.7"
                implementation "com.squareup.sqldelight:coroutines-extensions:1.4.0"

            }
        }
        jvmMain {
            dependencies {
                implementation kotlin('stdlib-jdk8')
                implementation "com.squareup.sqldelight:sqlite-driver:1.4.0"
            }
        }
        mingwMain {
            dependencies {
                implementation "org.jetbrains.kotlinx:kotlinx-coroutines-core-native:1.3.7"
                implementation "com.squareup.sqldelight:native-driver:1.4.0"
            }
        }
    }
    sqldelight {
        Database {
            packageName = "com.gunnarss.multiplatform"
        }
    }
}

The error is

Could not resolve com.squareup.sqldelight:coroutines-extensions:1.4.0.

I can either have windows as a native target OR I can get the extension, not both. If' I'm understanding the docs correctly, the above gradle should work?

Does it makes sense to create a OM layer (for SQLite) with incrementally updated queries, where the query cache is maintained using "materialized view maintenance" techniques? (I am thinking of code generation for each query, like in SQLDelight)

Is there a Retrofit-level request interceptor where I could process annotations like

@ApiVersion(2)
fun remoteCall() : Call<ResponseBody>

or are interceptors only at OkHttp level. (I want to add a query parameter to the annotated endpoints)

you can read the annotation by grabbing the

Invocation

in an interceptor

is there snapshot versions of sqldelight available anywhere? also is the gradle plugin published anywhere so that it can be added just as

id("com.squareup.sqldelight")

? or do i have to compile and publishTOMavenLocal if i want to try out the development state ?

snapshots are published to https://oss.sonatype.org/content/repositories/snapshots/

we publish a plugin marker to maven central, so you have to tell the funky plugins block to use that instead of the proprietary plugin repo that Gradle uses which we do not publish to

the IDE plugin also has an EAP channel which is effectively snapshot builds: https://plugins.jetbrains.com/plugin/8191-sqldelight/versions/eap

i guess there is no way to update the idea plugin to eap from within idea ?

guess thats why i did not find it