yeah i feel like you need to pull out two modules here, db-prod and db-dev. can't think of anything else

ended up just fixing up my package setup a bit and then just back-porting (read: copy/paste) tables back to dev schema with a big comment that says "don't change this unless you change the prod copy too." that was enough to allow dev tables to write joins that reference prod ones

going the multi-module route was going to force us to make a bunch of other unrelated decisions about visibility of important classes that we weren't ready to take on

anyway, that's how it ended up

I see that the sqldelight JS sample project was purposefully broken to be compatible with Kotlin 1.3.* and coroutines 1.3.5. I’d like to know if a Sqldelight project can still be built with JS, iOS and Android targets using Kotlin 1.3* and coroutines 1.3.5? If it IS possible, my followup question is do I still need to clone the JS driver and import it as a local module? Or is there now a published artifact I can grab from somewhere?

It is not published yet

Is anybody here working on the Cash App Paparazzi library? I had a thought/realization that I'd like to chat about rather than open an issue on GitHub right away.

no idea if he checks here

GitHub is generally a better forum since it's available to everyone and can happen asynchronously

👋

ContourLayout

question. Can I somehow achive the following: child view is laid out using

wrap_content

if it has

width < parent.width()

but otherwise it stays at

parent.width()

. In short I want

center_horizontally + width=min(width, parent.width())

.

ConstraintLayout

has some magic flags for this (layout_width=0dp + constrainedWidth + constraintWidthDefault=wrap). I tried

leftTo { parent.left() }.rightTo(sizeMode = AtMost) { parent.right() }

but this does not center the view, altough it does forbid it to grow beyond parent. @saket lightest ping :)

I figured this out:

centerHorizontallyTo { parent.centerX() }.widthOf(SizeMode.AtMost) { parent.width() },

It's an almost literal translation of the "in short I want" rule I've written above. Man,

ContourLayout

is awesome! 👏

glad you were able to figure it out!

I often keep forgetting that

widthOf

and

heightOf

take size modes

Guys, I checked sqldelight's source code, and it seems that the lowest sqlite version is 3.18. Per android docs, 3.18 comes with Android API 26, but my minSdk is much lower and because of that my users might have pre 3.18 versions. Am I risking some runtime errors by accidentally using features that are not supported pre 3.18? Pardon my english.

that's the dialect version, not the lowest supported version

i'm just worried that i'm risking some runtime error, because of some queries with unsupported dialects for pre 3.18. I did some research about shipping app with my own sqlite, so I can have same version on all API's, but I found nothing. Is that even possible?

you can use requery for bundling your own sqlite https://github.com/requery/sqlite-android

alec and i spoke about automatically mapping your minSdk to the correct dialect version

but it's a nice-to-have at this point

yep, combination of requery with a little bit modified version of sqldelight's android-sqlite-driver might give consistency across different OS.. gonna give it a try later. thanks!!!

we ship with requery. it's nice being able to control your sqlite version

Can you directly set the sqldelight's starting database version, or do I need to create tens and tens empty .sqm files? I want to have matching database versions for room and sqldelight, so they can coexist until I fully migrate to sqldelight. What's your experience with migration to sqldelight?

you just need an empty .sqm file for the version - 1

so like 83.sqm if you’re at 84

and it can be empty

thanks, I'm feeling dumb, I thought (number of .sqm files) = version -1

saved my time

just some random thought about sqldelight's coroutine extensions:

@JvmOverloads
fun <T : Any> Flow<Query<T>>.mapToOne(
  context: CoroutineContext = Dispatchers.Default
): Flow<T> = map {
  withContext(context) {
    it.executeAsOne()
  }
}

wouldn't it be more idiomatic to use

flowOn

instead of

withContext

?