Thanks guys.
I'm now using Json.Decode.Value and build a very forgiving decoder on top
of it and it seems good enough for now.
Will consider versioning schema if I need more control on that.


On Wed, Nov 9, 2016 at 1:14 AM, Kasey Speakman <[email protected]> wrote:

> I would additionally make each migration function only go from one version
> to the next version up. Then chain them together up to the latest version.
> That way you only have to make 1 migration function for each version bump
> and leave the others untouched and still upgrade from any previous version.
>
> I think you'd have to have an intermediate format for the migration...
> like first decode whatever was stored into a Dict String Value. Then only
> decode, modify, and re-encode the changed model parts in each migration
> method. Then at the end, take the Dict String Value and decode that into
> the current model.
>
> loadModel : String -> Dict String Value -> Result String Model
> loadModel dataVersion d =
>     case dataVersion of
>         "0.0.1" ->
>             Dict.insert "aNewProperty" (Encoder.string "A Default Value") d
>                 |> loadModel "0.0.2"
>
>         "0.0.2" ->
>             Dict.remove "anOldProperty" d
>                 |> loadModel "0.0.3"
>
>         // at latest version
>         "0.0.3" ->
>             decodeModelFromDict d
>
>         _ ->
>             Result.Err "Invalid Version"
>
>
> This is just an idea. I haven't tried it.
>
> On Tuesday, November 8, 2016 at 9:20:56 AM UTC-6, Peter Damoc wrote:
>>
>> You could load the raw data into the app using Value instead of whatever
>> you have now and create a series of Json Decoders for each version of the
>> schema.
>> You could then use Json.Decode.oneOf to produce the current structure
>> from any of the old schemas.
>>
>> You could also use a schema version field on the data and then do the
>> decoding in two parts using Json.Decod.andThen
>>
>>
>>
>>
>> On Tue, Nov 8, 2016 at 5:02 PM, Jacky See <[email protected]> wrote:
>>
>>> I have an Elm app that would store the entire model into the local
>>> storage, using `programWithFlags` to feed in the data directly when `init`.
>>> As the app develop, more fields is added to the model so there will be
>>> model mismatch between localStorage and the new model and Elm would fail at
>>> the JS side when trying to init.
>>> Obviously, there should be some migration plan here at the js side to
>>> update the stored model to the new shape.
>>> Personally, I wish I could have something like Json.Decode to handle the
>>> model directly in Elm, maybe peform a task?
>>> What would you guys recommend to do?
>>>
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "Elm Discuss" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to [email protected].
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>>
>>
>> --
>> There is NO FATE, we are the creators.
>> blog: http://damoc.ro/
>>
> --
> You received this message because you are subscribed to a topic in the
> Google Groups "Elm Discuss" group.
> To unsubscribe from this topic, visit https://groups.google.com/d/
> topic/elm-discuss/XmpH3W4qs58/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> [email protected].
> For more options, visit https://groups.google.com/d/optout.
>



-- 
Best Regards,
Jacky See

-- 
You received this message because you are subscribed to the Google Groups "Elm 
Discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
For more options, visit https://groups.google.com/d/optout.

Reply via email to