kotlin nullable type property

[endink]

Recommended to determine whether the database is allow NULL to generate an mode property type is nullable or not nullable (without ? ), otherwise there are a large number of kotlin emphasis symbols (!!) in the code.

[jeffgbutler]

I understand the ask - but there are some tradeoffs. I chose to make everything nullable so it would be easy to provide in initial value of null to all fields in the data class. This means that you can instantiate the class without providing all the values in the constructor. But I know this is not strictly idiomatic Kotlin.

Other considerations are that the JDBC driver won't necessarily give a correct answer about whether a column is nullable, and most columns in a typical database are nullable anyway.

Given all that, here are some thoughts...

1. We could trust the JDBC driver and assign nullability based on what it tells us. This will change the current strategy of building data classes - they will only be able to be instantiated through their constructors.
2. If we go this far, we could go further and make the data classes immutable (val instead of var)

What do you think?

[endink]

First, thanks for your reply, in my opinion:

1. Just consider the the database driver has provided NULLABLE metadata, if not , keep nullable.

2. Use the convention with initial value ( default value ) for the non-nullable field is better than providing all the values in the constructor, in fact, a lot of program language do.

consider follow value convention ( C# do this ):

- Number(Int, Long, Double....etc): 0
- String: ""
- bytes[]: ByteArray(0)

etc.

I think simple convention is better than complex configuration .

3. I think make the data classes immutable is a bad idea, it will be bring a lot of trouble in some scenes : data deserialization, bean copy....etc

4. It may be possible to provide a switch on or off non-nullable feature in the configuration file to maintain the compatibility of the current strategy.

[endink]

sorry for my bad English, lol

[jeffgbutler]

The problem with defaults is that there are not good defaults for all the possible types. What should a default Date be? Or what about some custom type? So I think with defaults, it's either null or nothing.

I think I agree with you about immutability.

I use this project to document patterns for Kotlin with MyBatis: https://github.com/jeffgbutler/mybatis-kotlin-examples - I'll work on some updates in that project based on these ideas and we'll see what emerges.

[endink]

Okay, looking forward to your updates ！

And hope another problem with mybatis dynamic sql can be improved in new release.

class AbstractFunction<T, U extends AbstractFunction<T, U>>

This generic constraint greatly limits AbstractFunction. Because it requires that the type of function returned has the same the type as incoming column.

consider mysql st_distance function, input type is point ( as byte array in Mybatis ), and return double, so AbstractFunction cant be used.

A simple solution to fix that is add a generic parameter and use inheritance to be compatible with existing code:

class ComputeFunction<TInput, TOutput, U extends AbstractFunction<TInput, TOutput, U>>


class AbstractFunction<T, U extends AbstractFunction<T, U>> : ComputeFunction<T, T, U extends ComputeFunction<T, T, U>>

thanks !

[jeffgbutler]

Please make a new issue for this.

[endink]

ok , lets close this !