then next time you get an instance of your database it will recreate it

Gotcha that makes sense, for deleting it I’d be getting into just plain old SQLite on Android shenanigans, right? — Just want to make sure there isn’t a nice to delete the database from the SQLDelight database class

yea you have to use the context.deleteDatabase API i think

@alec any updates on postgres on sqldelight ? https://github.com/cashapp/sqldelight/issues/1009 i am now facing the issues of having to decide on a library or ORM for database access and sqlite is not a option, seems like jooq is going to be used for now

no updates yet

Just wanted to close the loop on the conversation in case someone else stops by with a similar question. This is roughly what the solution looks like and it seems to work as expected. Thanks for the help @alec!

Having trouble with

wire3

on Android with Gradle Kotlin DSL. It does not compile once I add the gradle plugin to the app level gradle file. I have the following in my gradle config right now-

Project level
-------------------------------------
buildscript {
    repositories {
        ...
        mavenCentral()
    }
    dependencies {
        classpath("com.android.tools.build:gradle:3.5.1")
        classpath(kotlin("gradle-plugin", version = "1.3.40"))
        classpath("com.squareup.wire:wire-gradle-plugin:3.0.0")
    }
}
--------------------------------------

App level
--------------------------------------

plugins {
    id("com.android.application")
    kotlin("android")
    kotlin("android.extensions")
    kotlin("kapt")
    id("com.squareup.wire")    // GIVES - "Task with name 'compileJava' not found in project ':app'." WHEN ADDED
}

android {
    compileSdkVersion(29)
    defaultConfig {
        applicationId = "<http://com.example.android.app|com.example.android.app>"
        minSdkVersion(23)
        targetSdkVersion(29)
        ...
    }
   
    compileOptions {
        sourceCompatibility = JavaVersion.VERSION_1_8
        targetCompatibility = JavaVersion.VERSION_1_8
    }
    sourceSets.onEach {
        it.java.srcDir("src/${it.name}/kotlin")
    }

     sourceSets.getByName("main")
         .java.srcDirs(file("$buildDir/generated/source/wire"))
}


// Wire
wire {         //  wire DOES NOT RESOLVE
    kotlin{}
}

val kotlinVersion = "1.3.40"
val wireVersion = "3.0.1"


dependencies {
    implementation(kotlin("stdlib-jdk7", version = kotlinVersion))
    ...
    implementation("com.squareup.wire:wire-runtime:$wireVersion")
    implementation("com.squareup.wire:wire-grpc-client:$wireVersion")
}

Anything that I'm missing here?

Move your protos to a separate module, depend on from app

Thanks Jake.

Any idea on when the gradle-plugin will start supporting Android?

What would be the most efficient way of doing the following(with `moshi`/`okio`): Inside an abstract jvm server, stream json(gzipped , from another server) as a response to the client, while reading json values from predefined number of keys using, and after streaming is done using them elsewhere. The goal is to minimize allocations and only load values that are needed. Do upcoming

moshi

apis such as

valueSink

and

valueSource

are good choice for that? @jw

Hi all! At some time I se error in log:

W/SQLiteConnectionPool: A SQLiteConnection object for database '/data/user/0/ru.myapp.agent/databases/myAppAgentDB0.4.db' was leaked!  Please fix your application to end transactions in progress properly and to close the database when it is no longer needed.

How to close database?

@jrod Does this mean Paparazzi could be used to test Compose views as well?

hey SqlDelight question, we now have multiple tables within a single database. To test, we are using instrumented espresso tests. I want to ensure a clean database at the start of each test run - previously i was dropping the only table in the database and then recreating the schema: but now with multiple tables i’d have to drop each table in the schema. Is there a way to drop all tables, or to drop database? Just seeing if there’s something cleaner than iterating through like so

for (each table in database) { drop table }

To test, we are using instrumented espresso tests.

Depending on what you are testing you also are free to write the tests to run on the JVM. We are doing that with a project I’m on right now and it has worked out well. I’m assuming there is the potential for some variances since we aren’t using the Android SQLite driver on the tests but haven’t ran into any issues yet.

Hi!

sqldelight

question. Say I have a query like

SELECT column1 FROM table WHERE column2 IN ?

If I pass an empty list I guess it will return an empty row set. But what if I want to pass an empty list and get ALL rows in this case. Do I absolutely have to have 2 almost identical queries for this (second being one without an

IN

)? Asking because in my case query has quite a complicated

WHERE

clause, I'm afraid maintaining 2 versions of it could be prone to forgetting.

You can introduce a view for the WHERE clause

I thought views can't have

?

parameters, will re-check.

Views work just like tables. You can't have a

?

in the creation of the view, but when you query it you're more than welcome to.

Hm, I have complicated migrations I can't do from a sqm but need to do them in code. I did that by overwriting the schema, but now I lose all testing functionality. I digged a bit in the source code and it seems that there the logic is already decoupled in the migration module but the logic for creating the statements from sql is deeply deeply integrated in the VerifyMigrationTask which I can't run from a junit test

Is there no way I can unit test my code migrations?

Views work just like tables. You can't have a ? in the creation of the view, but when you query it you're more than welcome to.

Yeah, the thing is that in my case WHERE has quite a few conditions, so I didn't want to duplicate it only because

IN ?

doesn't handle case when

?

is an empty collection. But don't think it actually should, just thought there maybe some pattern I don't know about. For now I duplicated my query.

Curious about techniques people here have implemented: how do you keep your views up to date with changes made to Sqldelight tables? Example: an api call returns a value which will be added to a row in your table. The view on the screen shows a count of the number of rows in that table, how would you get that data from the db to the view? Options in my mind are a) to asynchronously query the table once you receive a callback in your Presenter, then updating the view or model then view b) (somehow) View listens to the table change c) in-memory cached model which you separately increment in the Presenter’s api callback, which non-directly ends up tracking the values in the table (benefit here being cached + database backed if the app gets killed/reopened) Option C is what we’re doing now and i’m questioning whether the performance benefit outweighs the need to keep an extra version of what is in the tables

rxjava or flow

there are sqldelight extensions for them

@alec

val players: Observable<List<HockeyPlayer>> = 
  playerQueries.selectAll()
    .asObservable()
    .mapToList()

re rxjava: here’s the example from the readme. if properly set up, would the table be able to emit the added/changed HockeyPlayers, or the entire list? Or does it need to be explicitly queried

it always emits the entire list every time any of the underlying results change

ah i see, i’ll give it a try! rather than using queries like a data stream, I’ve been using the tables by querying them when i’m interested in data

So moving in the direction of powering the views of the application based on Sqldelight/Rxjava query returns, how can you be confident that these views are loading in a fast and smooth manner for the user? Is there a way to monitor performance of all sqldelight queries/streams to monitor performance over time to make sure nothing is degrading