Can generated interfaces extends custom interfaces?

[ursusursus]

No description provided.

[JakeWharton]

No. What's your use case?

…

On Wed, Feb 6, 2019, 12:57 AM ursusursus ***@***.*** wrote: — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#1210>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAEEEbd0KGoQtI8iB-RY0ilaQCQGvzJaks5vKm7CgaJpZM4akmUQ> .

[ursusursus]

Im coming from Room, and I like having my enums nested inside such class.

data class Message(
    override val id: String,
    val type: Type,
    val subtype: Subtype,
    val user: String,
    val text: String,
    val isStared: Boolean,
    val timestampMicros: Long
) : Diffable<String> {
    enum class Type {
        MESSAGE, UNKNOWN
    }

    enum class Subtype {
        MESSAGE_COMMENT, UNKNOWN
    }
}

And sometimes I use Diffable interface

interface Diffable<T> {
    val id: T
}

class DiffCallback<T : Diffable<*>>(
    private val oldList: List<T>,
    private val newList: List<T>
) : DiffUtil.Callback() {

    override fun areItemsTheSame(oldItemPosition: Int, newItemPosition: Int) =
        oldList[oldItemPosition].id == newList[newItemPosition].id

    override fun areContentsTheSame(oldItemPosition: Int, newItemPosition: Int) =
        oldList[oldItemPosition] == newList[newItemPosition]

    override fun getOldListSize() = oldList.size

    override fun getNewListSize() = newList.size
}

Minor: Im a bit uneasy that my model basically doesnt exist in kotlin, only as sql table schema, Id like just a marker interface (but I know you going to argue with join results)

[JakeWharton]

One way to workaround that would be to supply a property reference in the constructor.

class DiffCallback<T>(
  private val oldList: List<T>,
  private val newList: List<T>,
  private val idSelector: (T) -> Long
)

Then you'd have to pass MyModel::id to the constructor.

[ursusursus]

Yea lambdas could work

In cash app / other production apps using sqldelight, you dont have a central Foo type? Everything is just a unrelated mapped projections of the queries even on same foo table, exposed all the way to the ui (unless some transformation in kotlin is necessary to parse it out - like grouping of lists etc, but not necessarily transforming from "db" to "domain" model)?

[AlecKazakova]

yup. We select the subset of data from our schema we need for the UI/logic, and operate directly on that.

For times where we want a single type to be used in multiple locations we use sqlite views, which essentially create a type over some projection, then you can select from that projection and receive the same type everywhere.

[JakeWharton]

And if I hadn't been lazy I'd have a blog post about the view stuff out today. Next week!

[ursusursus]

When I think about it, we all did this back in cursor days and nobody complained, but then we got corrupted by server side orm styles and select *

Thanks!

[ursusursus]

btw @AlecStrong do you have some rule of a thumb on naming of these subset projections?

also, projection is named after label of the operation, where in selects, id most likely expect the label / kotlin method to be plural, and then projection interface singular

[AlecKazakova]

nothing obvious no. I usually tie it to the views we're using the projection in. For Cash App we have a payment and customer table, but those are joined in an activity view which is used to power the activity ui.

Yea I see what you mean: getAllPayments has a method getAllPayments but then a type GetAllPayments. Another reason to use views! you have tighter control over the name since the result type will be the view name if you SELECT * from the view

[ursusursus]

Well yes, but for regular selects its kind of weird. I don't think full-blown name overriding is worth it but some convention for "if select label ends with "s" then -s from interface type" would be helpful I think. Its only natural to have getPayments(): List<Payment>

But now thinking about it, getAllPayments: List<AllPayment> is silly also. Maybe some syntax for select labels like getAllPayments, Payment ?

[JakeWharton]

I definitely have problems with the naming. I alter my query name to be singular to work around it.

…

On Wed, Feb 6, 2019, 8:53 PM ursusursus ***@***.*** wrote: Well yes, but for regular selects its kind of weird. I don't think full-blown name overriding is worth it but some convention for "if select label ends with "s" then -s from interface type" would be helpful I think. Its only natural to have getPayments(): List<Payment> — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#1210 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAEEEQEnqcWOJwsoK69eDIIW7-tbM2zmks5vK4cNgaJpZM4akmUQ> .

[ursusursus]

btw @JakeWharton Ive found such use case. Imagine ui with 3 tabs displaying list of items, where each tab is just different WHERE over the same table (and most likely same projection, or superset). Therefore each tab extends BaseFooPresenter which has abstract method query(): List<Foo>. Mapping manually to some MappedFoo would obviously work, but having AFoo BFoo CFoo related (since its the same projection on the same table) via some Foo interface out of the box, would be nice

[JakeWharton]

You can use a view to ensure they use the same type. I'm working on a blog post to cover this case.

…

On Wed, Feb 13, 2019, 11:52 PM ursusursus ***@***.*** wrote: btw @JakeWharton <https://github.com/JakeWharton> Ive found such use case. Imagine ui with 3 tabs displaying list of items, where each tab is just different select over the same table. Therefore each tab extends BaseFooPresenter which has abstract method query(): List. Mapping manually to some MappedFoo would obviously work, but having AFoo BFoo CFoo related via some Foo interface out of the box, would be nice — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#1210 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAEEETKwIN01Mkk_ot-DNIcBGVHGAqEwks5vNOuTgaJpZM4akmUQ> .

[ashughes]

@JakeWharton Any update on the blog post? ;-)

[JakeWharton]

Er yeah I'll get back to it

…

On Wed, Feb 27, 2019, 7:40 PM Andrew Hughes ***@***.*** wrote: @JakeWharton <https://github.com/JakeWharton> Any update on the blog post? ;-) — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#1210 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAEEETnZ7wUhhqE6g27_DbfE5dTVOOc1ks5vRyVxgaJpZM4akmUQ> .

[ashughes]

Any chance I missed the blog post?

[JakeWharton]

Nope. Just being lazy / busy.

…

On Sat, Jul 13, 2019, 5:50 PM Andrew Hughes ***@***.***> wrote: Any chance I missed the blog post? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#1210>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAAQIEPJSC3BPHVLUFJ3PJ3P7JEYZANCNFSM4GUSMUIA> .

[ursusursus]

Imho sql views are overkill, they need to be migrated etc. I only want a common type for polymorphism sake. This is advantage of Room. However here I'm afraid only passin in the mapper interface and mapping manually to type which has the interface is only solution?

[JakeWharton]

Yep. We prefer views and pushing people towards them.

…

On Sat, Jul 13, 2019, 6:30 PM ursusursus ***@***.***> wrote: Imho sql views are overkill, they need to be migrated etc. I only want a common type for polymorphism sake. This is advantage of Room. However here I'm afraid only passin in the mapper interface and mapping manually to type which has the interface is only solution? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#1210>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAAQIEOGYLKTZRBJKECNP3LP7JJQ5ANCNFSM4GUSMUIA> .

[ursusursus]

Well, views have their limitations, I think somehow intercepting the name of the query and passing in custom type would be cleaner. Or maybe somehow signal to the plugin that dont create wrapper type for selection, mapper will be passed to you

[ursusursus]

What people usually do is have root type Entity, which has id field, so that can be used in generic crud functions on some kind of abstract store class

[ursusursus]

Here is a real life example I encountered today

messageIdsByChannel:
SELECT id, remoteId
FROM message
WHERE remoteId IS NOT NULL AND channelId=? AND accountId=?;

messageIdsByThread:
SELECT id, remoteId
FROM message
WHERE remoteId IS NOT NULL AND c_messageRemoteId=? AND accountId=?;

This projection is represented by the same data class, and it makes 0 sense to make it a view