Nope it's in the right place. SQL Delight is worked on by volunteers and is not something you pay for so you're at the mercy of the time and attention of its contributors.

I accept bribes

are there docs for gradle.kts and SQLDelight I onlt found this : https://github.com/cashapp/sqldelight/issues/1604

Funny why Timber logging doesn't include a lambda form for all the log level's messages (now that it's in Kotlin)... sometimes we call heavier procedures to generate logs when there's errors... formatting might not be done, but the code is still run to get all those params into the formatter... I always need this lib: https://github.com/ajalt/timberkt... but it hasn't been updated in a while...

That is basically useless since the conditional is whether there are zero trees

Even in production you should have a tree installed queuing logs at higher levels in a ring buffer for use in crash reporting

The correct way to do this would be to have trees report the levels supported and for the conditional to check that

Even when the tree filters out debug logs, if you have

Timber.d("Some Log %s", someHeavyOperationToCalculateTheString())

you'd have to clutter the code with

if (BuildConfig.DEBUG)

before each of those so that the heavy operation won't be called... whereas if the Tree is configured to filter out debug logs a

Timber.d { "Some Log ${someHeavyOperationToCalculateTheString()}" }

would be sufficient...

With the lambda only called if the tree doesn't filter the log out...

That is what I'm proposing. That is not the behavior of the library you linked.

Yeah, true, I just linked it for the idea... but that's really why I think that if it was integrated into Timber it would be even better 😃! Also wondering if there's any plans to make the Timber api separate from Android (maybe a seperate module)... that would allow to include it in domain modules with no Android dependencies... it would also prepare it for use in KMM.

Do most folks use 🌲 timber or 🐈 logcat https://github.com/square/logcat these days? I'm starting a new project and although logcat calls out "why not timber", I'm curious if there's still a community preference.

Wow! Didn't know about that one 👍🏼... For more complex needs maybe Timber is better, but logcat certainly looks interesting for our current project.

It might still be nice to have the lambdas in Timber though... now that it's in Kotlin.

I hope that's not too bad of a practice, but we use Timber in production in another project to send critical logs to crashylitics, I guess logcat wouldn't do in that case...

Should Kotlinpoet add all necessary imports by itself?

Yes, if you use ClassName and the like everywhere

But not when using plain (?) PropertySpec? Usecase/Bug: SQLdeligt with dependency databases: The adapter for the parent db is not imported correctly

You can file a bug with sufficient information to reproduce or with a sample project that demonstrates the errant behavior and we'll take a look

I'm already doing it, https://github.com/cashapp/sqldelight/issues/2754

You could make the type nullable and use an annotation to conditionally do the validation in the serialization layer

That way it can apply to any type and the logic of when it's enabled is entirely encapsulated in one place

You would do this with a JsonAdapter.Factory which checked for the annotation and then conditionally wrapped the delegate JsonAdapter with one that threw and exception upon a null value

Cool. I guess that would be "more performant" then just having another layer (lets call it validation layer) after the deserialization layer, that just "inspects" if all of the values follow whatever invariants that the BE team "promised" us?

Performance won't really matter. It'll cost less than 1% of the cost of actually deserializing the data either way.

runBlockingTest is truly awful and likely the cause

@Colton Idle The requirement to crash in internal builds but not in production is misguided and will cause you pain. Not crashing on unexpected nulls means that production will exercise a potentially very different code path than what you're testing. For example, suppose your code echoes a null back to the server in a save() call. What will that do? Does it fail silently? Delete the corresponding field? Replace null with a default? You won't find out in development, and you'll be really confused why you can't reproduce these data corruption bugs.

Oh I know. I think it's terrible. Unfortunately my lead think its a great idea. 😭

Square is hiring... right? 😄

Do Okio buffers support memory efficient random access? Something like a direct ByteBuffer in Java? I'm processing very large files and want to keep as little in memory as possible.