how do you feel about having different objects for writing and reading database objects? Writing an object will for instance not require an id whereas querying an object will always have one. Otherwise I have to add null checks everywhere.

How about this?

class DbEntry<ID : UUID?>(val id: ID, val name: String)

typealias SavedDbEntry = DbEntry<UUID>
typealias UnsavedDbEntry = DbEntry<Nothing?>

neat trick however I'm also using this to generate a swagger api

No. It's

Nothing?

, not

Nothing

.

what happens if the user sets it in Java though

They can set it to null

and also to a value?

Sure

Is there a reason you don’t want to just use different objects for input vs output?

@tddmonkey that's what I was thinking as well. Just wanted to get some feedback since I need some boilerplate code for that which converts between these objects (e.g. fetch object from db, update value and save it)

I am not sure why that is better than my typealias solution

That feels like it solves a single issue of the type - what about when the difference is larger?

I am not sure I follow you

When the representations differ by more than just having an ID or not

You could add more type parameters. The problem with having two classes is that there is no easy way to convert between them without spelling out all attributes again.

ymmv. tbh I use this technique a lot and don’t usually find myself converting between them so much

don’t usually find myself converting between them so much

Not sure how you are doing this. You will need to write a separate

saveToDb

function for every type you have...

The majority of my work is in RESTful BE services, so there will be a

GET

endpoint for a client to retrieve data, then a

PUT/POST

endpoint to update data. There’s no read-update-write cycle inside my service

Well, that is a totally different scenario. The original question was about database objects.

I don’t see how - I’m still reading and writing to a database

The way I understood the question:

val unsaved = UnsavedEntity(... data ...)
// unsaved.id does not exist / is null
val saved: SavedEntity = db.save(unsaved)
println(saved.id) // guaranteed to be not null

Inside

db.save

you need to go from

UnsavedEntity

to

SavedEntity

.

If you need to return a saved representation straight away, perhaps. I typically don’t see that though. I’m coming from the point of view of a more CQRS approach where the representations can happily differ and there’s no need to treat them the same if they don’t have to be. If your saved object is truly and always going to be the same as a new object, but with an ID then yeah, code sharing is probably the right way to go. My experience is typically that they have a tendency to diverge, and when that happens I don’t want to try and shoehorn a representation in that doesn’t quite fit, just because I used the same class.

I agree with you, it seems we just understood the question differently.

Out of interest - why would you go the

typealias

route instead of having a (potentially reusable) container object to represent the saved state and using composition? Say something like: class SavedItem<T: Any>(val id: UUID, val item: T) Then you either use

User

or

Saved<User>

as necessary in the right place?

That would also work, but has the disadvantage of having to do another hop "all the time" (

user.item.name

instead of

user.name

).

Inheritance + delegation?

Can't delegate to a

data class

😄

Hmm, yeah, messy

Database access is always messy... It's one of my constant pain points in any language.

tbh I try to architect my systems to avoid as much of that mess as possible