I don't know if I want to allow this, but it might make sense to have an option in the mapper to allow fields to be null. Right now, if you use bean properties with ConfigMe, you have to understand very well what needs to happen in order for a new field to be added, without that the user loses all data:
need to probably define a copy of the class with any new fields as Optional
in the migration service, load property as that and replace any Optional.empty with a value
-> this only saves the new values to the config file, but the actual bean property is already converted and used in the application, i.e. for proper migration, also this:
convert from the class with Optional to the current bean class and set that value as the bean property
I don't think there's a way to reduce the number of steps, but it would make sense to maybe have a method on the mapper that can create objects with a null field? Then we wouldn't need to maintain a copy with Optional-typed fields.
Ultimately, also for bean property values, if a user wants to have null values, I still think it's not in the philosophy of ConfigMe, but there's also no point in standing in the way of that. It still doesn't break the core ConfigMe philosophy since the bean itself is never null (but one of its fields might be...)
I don't know if I want to allow this, but it might make sense to have an option in the mapper to allow fields to be null. Right now, if you use bean properties with ConfigMe, you have to understand very well what needs to happen in order for a new field to be added, without that the user loses all data:
Optional
Optional.empty
with a value -> this only saves the new values to the config file, but the actual bean property is already converted and used in the application, i.e. for proper migration, also this:Optional
to the current bean class and set that value as the bean propertyI don't think there's a way to reduce the number of steps, but it would make sense to maybe have a method on the mapper that can create objects with a null field? Then we wouldn't need to maintain a copy with
Optional
-typed fields.Ultimately, also for bean property values, if a user wants to have null values, I still think it's not in the philosophy of ConfigMe, but there's also no point in standing in the way of that. It still doesn't break the core ConfigMe philosophy since the bean itself is never null (but one of its fields might be...)