avaje / avaje-config

Application configuration / properties loading for JVM applications
https://avaje.io/config
Apache License 2.0
51 stars 8 forks source link

Implement support for most TOML types #173

Closed Mechite closed 4 weeks ago

Mechite commented 4 weeks ago

With the original implementation in my PR, arrays were not supported, and the other types in TOML were not specifically tested. Feel free to make changes to the unit test, if you find this too bloated.

TOML types: string, integer, float, boolean, offset date-time, local date-time, local date, local time, array, table

string, integer, float, boolean

All working before

array

I have implemented arrays by deserializing their contents well, and joining with ;. This is how environment variables work, and properties seems to have common conventions.

I am unsure how Avaje Config supports lists, currently. Is it by repeating the same key multiple times, with each value? If that's the case I could implement it this way instead.

local date, local time, local date-time, offset date-time

Maps to JVM - LocalDate, LocalTime, LocalDateTime, and OffsetDateTime. They have direct implementation in TOML, and the toString() is called from the JVM class to give us a string in the map. This leaves us with an ISO-8601 value.

This value can be immediately passed in to the static parse methods, e.g. LocalTime#parse, if someone wants to use these TOML features easily. var time = LocalTime.parse(Config.get("some_localtime"))

table

Intermediary tables are not supported, but the normal tables are "un-nested", i.e., dotted, and this was working before.

Intermediary table: some_key = { one: 1.0, two: 5.0 }

I don't know yet if it would be worth implementing this, because with the API that avaje-config exposes, it would be hard to actually use them?

For basic ones like this, the parser can be further expanded to "un-nest" them, i.e. make new dotted keys for their contents

But what about intermediary tables, in arrays? Users can't read them with our API right now, so they shouldn't use them If using them, the value will read org.tomlj.MutableTomlTable@2u0rjqai, etc.