Has anyone figured out a good way to serialize/des...

# exposed

[Robert Kempton]

Has anyone figured out a good way to serialize/deserialize an Entity? I'm using a data class DTO as an intermediate for now, but there's soooooo much boiler plate...

[jmfayard]

Are you talking about something like this?
https://shapeshift.krud.dev/

We wanted to try it but didn't yet

[Robert Kempton]

I'm specifically talking about serializing/deserializing an object that extends the exposed Entity class to json. I'm using jackson currently, but am not opposed to using a different serializer like gson or kotlinx.serialization to get this working.

I keep running into an issue where "klass must be initialized" when deserializing because of an internal field that holds a reference to the class. I'm not sure how to correctly fix that.

It also seems like instantiating an Entity might require an active transaction, which would also be difficult to work around.

That library doesn't look like it would reduce boiler plate, it would just be different boiler plate.

[jmfayard]

That library solves another purpose, please ignore

[maxmello]

I personally like the approach using DTOs, because it gives much needed flexibility, for example having different DTO classes for create, update and read endpoints, or have multiple DTOs for different types of consumers (maybe some internal properties should not be ‘leaked’ to external users). I usually have my entities extend an interface to ensure they implement a toDTO() method, and the DTOs have an interface to ensure they implement toEntity(). Finally, it allows you to change the table/entity classes without changing the API of your service directly, which could also have benefits down the line.

[Gustav Elmgren]

Same here, I found the boilerplate to be a bit much. So I created a related DTO, with the same names as in the table. And then via reflection created the DTO instance, if the name and returntype matches. Might be stupid, but that was the route I went for.

[Robert Kempton]

@maxmello It certainly has it's benefits, it's just obnoxious to see the same field list 5x. 1 for the table, 1 for the entity, 1 for the dto class, 1 for toDto and 1 for toEntity

[Robert Kempton]

@Gustav Elmgren I think you might be right that just using reflection might be the easiest option at this point. I'll probably give that a whirl.

[tapac]

You can take a look at https://github.com/TouK/krush
while https://github.com/JetBrains/Exposed/issues/24 is not implemented yet.

[Robert Kempton]

ooo that looks pretty promising, thanks for sharing