dust identifies the fields by conducting an fnv64_hash on the model name and the field name. This creates a strong binding to the name of the models that you defined. Hence, this prevents you from changing the name while still preserving the data in dust.
Implementation
To allow refactoring of names for the dust side, we should implement an additional annotation for the fields called ModelName, and add a modelName field to the class.
Say that you have a todo class:
@Model()
class Todo with _$Todo {
Todo._();
factory Todo({required String name}) = _Todo;
}
And you realized that instead of calling the field name, you want to call it title. Instead of calling the model Todo, you want to call it Task. Your old data would not be usable after the name change with the current state of dust. With this proposed implementation, you have:
@Model(modelName: "Todo")
class Task with _$Task {
Task._();
factory Task({@ModelName("name") required String title}) = _Task;
}
And dust would need to still generate the fnv64 hash using the "Todo" and "name", while naming the model "Task" and the field "title".
Motivation
dust
identifies the fields by conducting anfnv64_hash
on the model name and the field name. This creates a strong binding to the name of the models that you defined. Hence, this prevents you from changing the name while still preserving the data indust
.Implementation
To allow refactoring of names for the
dust
side, we should implement an additional annotation for the fields calledModelName
, and add amodelName
field to the class.Say that you have a todo class:
And you realized that instead of calling the field
name
, you want to call ittitle
. Instead of calling the modelTodo
, you want to call itTask
. Your old data would not be usable after the name change with the current state ofdust
. With this proposed implementation, you have:And dust would need to still generate the
fnv64
hash using the "Todo" and "name", while naming the model "Task" and the field "title".