Replies: 1 comment 1 reply
-
Yes, although in practice it's not that much code. Moor takes care of the direction from the database to your class, you just have to add the fields as parameters to the constructor. For the other direction (e.g. for inserts or deletes), you would want to use generated companion classes instead of using the data class directly. You could also refer to other generators like freezed or built_value to generate those methods for custom data classes. Moor does not have a mechanism to implement additional interfaces in generated classes. IMO, moor-generated classes should represent a row in the database only. There's no built-in concept of inheritance in SQL, so support for those things in generated classes is limited as well. Essentially, there are two options:
|
Beta Was this translation helpful? Give feedback.
-
Hi all, firstly, thanks for what looks to be a great project. I'm just trying to wrap my head around how to use the library properly... in particular, how to deal with subclassing / mixins.
Imagine I've got a superclass interface that looks something like:
and I wanted a few of my classes to
implement
this class.How can I make the generated
Dog
class implement thePet
interface? I saw #114 which looks like it was closed in favour of #1134 , however, if I understand #1134 correctly, I could create my ownDog
class but I would also be responsible for all the boilerplate to keep it in sync with the table. Is that right?Another approach I was considering was changing my table definition to look like:
and then declaring a new class:
There's still challenges here, though, because functions like
copyWith()
in the generated class won't return the aDog
... they're going to returnDogDatabase
.Have I missed a technique that will help here? I guess what I'm looking for is something like a
DataClassImplements
annotation that could be used to generate the appropriate code:Beta Was this translation helpful? Give feedback.
All reactions