For SQLDelight, is there a way to either subclass ...

# squarelibraries

[Garret Yoder]

For SQLDelight, is there a way to either subclass the generated data objects or provide my own over the generated? I'd like to include some extra stuff such as methods and implementations that are a little bit beyond modifier functions. Does subclassing the generated object 'just work' and if I pass it back to the library to store it it will work, and then just typecast it on fetch?

[hfhbd]

Nope, there is no builtin option to modify the generated classes, yet, like a plugin mechanism.

[Garret Yoder]

Could you subclass them? I'd assume it would just work but I haven't tried. Unless they're sealed/final

[hfhbd]

You can’t subclass a data class.

[Garret Yoder]

Oh its a data class not just a class, again I didn't look. Got it. Is there a place I should submit that as a feature request or is stuff like that already on the roadmap?

[hfhbd]

A plugin mechanism is on the roadmap, but don’t expect it in the near future.

[Garret Yoder]

Got it. Maybe just make the generated code a class instead of a data class? Then you could subclass it

[hfhbd]

Well, the generated class is a database record. Why do you want to subclass a record at all? What's your use-case?

[Garret Yoder]

I'm looking to include a composable function for displaying a widget of that data w/ each data object. That way they can all implement a common interface that requires this compose function, can be put together in a single list (where theres various different types of data) and then the UI can cleanly just call the display function on each object inside a container.

Right now I'm just converting each data object into a "data + compose UI" object class, but I was just hoping there'd be a way to cut that step out and include it with the original object

[Garret Yoder]

Helps modularize the code where the list doesn't have to be aware of the different kinds of items it's displaying.

[Garret Yoder]

Maybe an even cleaner solution would be for the generator to generate both an interface, and then a data class that implements that interface? Then you'd still have the data class that makes (I agree) logical sense, but you could implement that interface and extend if you wanted to

[ursus]

the query functions take a mapper lambda.. use that to return your own type