Coming from Java where nullability is sort of a free for all, I wonder how do you resolve this probl...

# getting-started

[poohbar]

Coming from Java where nullability is sort of a free for all, I wonder how do you resolve this problem.

I have a User data class which has a type field. The type can be either REGULAR or ADMIN. When it is of type ADMIN the user will always have a not null companyId but when it is a REGULAR user the companyId will always be null. Therefore the companyId now has to be nullable and I am forced to handle it even in this case:

val user = db.getUser(id)
if (user.type == ADMIN) {
  // user.companyId is definitely NOT NULL here but the compiler obviously has no idea
} else {
  // user is a REGULAR user so the companyId is null

The only way around this is to have two different classes: an AdminUser and RegularUser that will reflect the reality more closely. Is there a better way?

In Java the compiler does not care and I get no warnings.

[hho]

Different classes is probably the best way. Having flags that determine the presence of other fields is a code smell.

[poohbar]

Having a user type is a code smell?

[poohbar]

All the users are stored in the same database table. It is very common to map one table to one Java POJO.

[rarita]

Instead of having "type" field consider having different implementations of user. Thats what Henning Hoefer states i guess.

[spand]

You have to encode it in the types somehow. If your objection to AdminUser and RegularUser is duplication then maybe you should just have a val User.adminData: AdminData? that exposes these non null values

[poohbar]

I am just wondering how would you do it because it seems like a very common use case.

Would you really map one db table to two different classes?

[tddmonkey]

Could you have your “type” be a sealed class hierarchy where the Admin type has a non-null companyId.

[tddmonkey]

The compiler will give you the guarantees you want then

[hho]

@poohbar It is pretty common. In JPA it's called "Table per class hierarchy": https://www.baeldung.com/hibernate-inheritance#single-table

[poohbar]

I see.. yeah this is what I am doing. Most of my tables have a type column which determines their place in the "hierarchy". Except I didn't really model the hierarchy in my data classes.

[poohbar]

I guess I could completely hide the type from kotlin and only the function that maps the db row to data class would know about it and create the correct subtype of User

[Andreas Sinz]

How is your data mapped in the Database? A User-Table and another table Admin with a foreign key to User plus the companyId?

[poohbar]

no.. there is just one table called user

[poohbar]

it has a column type and nullable column companyId

[poohbar]

the companyId is only null when type is not ADMIN

[nfrankel]

if you’re using hibernate
there’s a mapping strategy for that
https://www.baeldung.com/hibernate-inheritance
#3 One table per class hierarchy

[poohbar]

jOOQ forever!

[nfrankel]

then you’re on your own...