Annotate generated classes

[vanniktech]

Description

Now that we can do id AS VALUE and version AS LOCK and there's also the json extension would it be possible to support Parcelable using an extension?

As for the syntax I'd imagine something like this:

import android.os.Parcelable;
import kotlinx.android.parcel.Parcelize;

CREATE TABLE @Parcelize foo AS Parcelable (
  id TEXT NOT NULL PRIMARY KEY,
  state INTEGER NOT NULL,
);

This only works when adding the parcelable extension similar to how the json extension works. Ideally, the same syntax can be used for CREATE VIEW.

---

It should also allow typealiasing to those types as when using Kotlin Multiplatform you usually do something like:

commonMain:

expect interface Parcelable

@OptIn(ExperimentalMultiplatform::class)
@OptionalExpectation
@Target(AnnotationTarget.CLASS)
@Retention(AnnotationRetention.BINARY)
expect annotation class Parcelize()

androidMain:

actual typealias Parcelable = android.os.Parcelable
actual typealias Parcelize = kotlinx.android.parcel.Parcelize

iosMain:

actual interface Parcelable

[AlecKazakova]

I would consider adding something so SQLDelight module extensions can annotate the generated type, but as I always say to feature requests like this - modifying the dialect is always always always my last resort and I don't think is necessary here, so the extension would just make every type that module is applied to extend parcelable, or you hardcode the types in your extension.

Anyways, unlikely to land a specific parcelable extension in SQLDelight but I think the ability to extend how a data class is annotated in an extension could make sense.

[vanniktech]

so the extension would just make every type that module is applied to extend parcelable, or you hardcode the types in your extension.

Sounds good

I think the ability to extend how a data class is annotated in an extension could make sense.

Sounds good as well

[hfhbd]

The biggest problem is the missing Kotlin representation. We currently use sql-psi and kotlinpoet directly. This works, but changing the generated kotlin representation is hard because kotlinpoet does not have a kotlin representation. Sure, you have typespec and all the stuff, but often we only use CodeBlock, which does not have any semantics.

Supporting parcelable by adding the annotation and the interface should be easy to implement, except advanced parcelable support.

But another use case, at least for me, is renaming the attributes of the query class. This does not only change the query class, but all usages too which is hard to implement with kotlin-poet only.

Edit: turns out, we already have some kotlin representation, for example IntermediateType and QueryResult. So I guess, column renaming could be implemented too. So open questions, what are the use-cases for this compiler api and which compiler steps are needed to intercept (and how).

[AlecKazakova]

Probably a lot, this would be a major feature though and I really want to just stay focused on fixes until we get 2.0 out

[hfhbd]

Absolutely 👍🏻