Closed CarpeNecopinum closed 2 years ago
@CarpeNecopinum Sorry, OMG, I missed this for so long! Is this necessary? Doesn't Julia handle the types if we just define the union, supporting all the types in the union?
I haven't used Genie for like half a year now, so I can't say how it is now for sure. But at the time of writing, SearchLight would always try to convert values read from the database into the concrete type (in the above example Missing
) rather than the field type (Union{String,Missing}
).
The _union_convert
then is a second step that ensures better backwards compatibility, because you can't convert
e.g. a Float64
into a Union{Int,Missing}
, but you can convert it to Int
. But that second part is basically optional, wheras the first part (https://github.com/GenieFramework/SearchLight.jl/pull/25/files#diff-15442cb6a676563c8cd8d8903211bbd55fadcdfeb0eca3f6bcd493cef2ac1d4cL700) is needed to support Union fields.
+1 Union types as model fields would be particularly useful for is_nullable columns in PostgreSQL. Any news on this?
Related to current discussions here: https://github.com/GenieFramework/SearchLight.jl/issues/55 Closing this issue in favour of the newer one.
It would be interesting to allow the use of models like:
Where the
cover
is effectively optional and by defaultmissing
. Unfortunately, https://github.com/GenieFramework/SearchLight.jl/blob/4e001f2044f5c64731c78545644db0ffe5871b16/src/SearchLight.jl#L394 blocks this from working, asoftype(Book.cover, x)
will callconvert(Missing, x)
which doesn't work forx
being e.g. a String.This PR changes that behavior in that we convert to the type of the field, rather than the type of its default value. The added function
_union_convert
handles cases like converting aFloat64
toUnion{Int,Nothing}
, which would not work withBase.convert
.