“可变”的最佳策略Erlang 中的记录

Question

我开发的系统假设会有很多用户。每个用户都有一个在应用程序内以记录形式表示的个人资料。为了存储用户的配置文件，我执行以下操作 base64:encode_to_string(term_to_binary(Profile))，因此配置文件基本上以序列化方式存储。

到目前为止一切都很好。现在的问题是：

我有时确实计划通过添加和删除其中的某些字段来扩展配置文件功能。我的问题是处理代码中这些更改的最佳策略是什么？

我目前看到的方法是做这样的事情：

Profile = get_profile(UserName),
case is_record(Profile, #profile1) of
    true ->
        % do stuff with Profile#profile1
        ok;
    _ ->
        next
end,
case is_record(Profile, #profile2) of
    true ->
        % do stuff with Profile#profile2
        ok;
    _ ->
        next
end,

我想知道我的任务是否有更好的解决方案？

其他信息：我使用的是简单的 KV 存储。它无法存储 Erlang 类型，这就是我使用 State#state.player#player.chips#chips.br 的原因

Answer 1

也许，你可以使用 proplists。

假设您已经存储了一些用户配置文件。

User = [{name,"John"},{surname,"Dow"}].
store_profile(User).

然后，几年后，您决定根据用户的年龄扩展用户配置文件。

User = [{name,"John"},{surname,"Dow"},{age,23}]. 
store_profile(User).

现在您需要从数据库获取用户配置文件。

get_val(Key,Profile) ->
   V = lists:keyfind(Key,1,Profile),
   case V of
      {_,Val} -> Val;
      _ -> undefined
   end.

User = get_profile().
UserName = get_val(name,User).
UserAge = get_val(age,User).

如果您获取“版本 2”的用户配置文件，您将获得实际年龄（在本例中为 23）。

如果您获得“版本 1”（“旧”版本）的用户配置文件，您将获得“未定义”的年龄， - 然后您可以更新配置文件并将其存储为新值，因此它将是“新”版本'实体。

所以，不存在版本冲突。

也许，这不是最好的方法，但在某些情况下它可能是一个解决方案。

Answer 2

它很大程度上取决于记录数量的比例、更改频率和可接受的中断。由于可维护性，我更喜欢首先将配置文件升级到最新版本。您还可以制作像 mnesia 一样即时升级的系统。最后，有可能保留所有版本的代码，这是我绝对不喜欢的。这是维护的噩梦。

无论如何，当守卫中允许 is_record/2 时，我更愿意

case Profile of
    X when is_record(X, profile1) ->
        % do stuff with Profile#profile1
        ok;
    X when is_record(X, profile2) -> 
        % do stuff with Profile#profile2
        ok
end

注意，没有 catch all 子句，因为您将如何处理未知的记录类型？这是错误，所以很快就会失败！

您还有许多其他选择，例如 hack like：

case element(1,Profile) of
    profile1 ->
        % do stuff with Profile#profile1
        ok;
    profile2 -> 
        % do stuff with Profile#profile2
        ok
end

或类似的东西

{_, F} = lists:keyfind({element(1,Profile), size(Profile)},
    [{{profile1, record_info(size, profile1)}, fun foo:bar/1},
     {{profile2, record_info(size, profile2)}, fun foo:baz/1}]),
F(Profile).

以及许多其他可能性。

Answer 3

最好的方法是拥有序列化（配置文件）的副本以及相同但以记录形式存在的副本。然后，每次对记录形式配置文件进行更改时，也会自动对同一用户的序列化配置文件进行更改（在同一事务中！）。修改用户记录配置文件的代码应该始终重新计算新的序列化形式，对您来说，这是用户记录的外部表示

-record(record_prof,{name,age,sex}).
-record(myuser,{
            username,
            record_profile = #record_prof{},
            serialized_profile
        }).

change_profile(Username,age,NewValue)->
    %% transaction starts here....
    [MyUser] = mnesia:read({myuser,Username}),
    Rec = MyUser#myuser.record_profile,
    NewRec = Rec#record_prof{age = NewValue},
    NewSerialised = serialise_profile(NewRec),
    NewUser = MyUser#myuser{
                    record_profile = NewRec,
                    serialized_profile = NewSerialised
                },
    write_back(NewUser),
    %% transaction ends here.....
    ok.

So whatever the serialize function is doing, that's that. But this always leaves an overhead free profile change. We thereby keep the serialized profile as always the correct representation of the record profile at all times. When changes occur to the record profile, the serialized form must also be recomputed (transactional) so as to have integrity.

Answer 4

您可以使用一些可扩展数据序列化格式，例如 JSON 或 Google Protocol Buffers。

这两种格式都支持添加新字段，而不会破坏向后兼容性。通过使用它们，您不需要向序列化数据结构引入显式版本控制。

在两种格式之间进行选择取决于您的用例。例如，使用 Protocol Buffers 更可靠，而 JSON 更容易上手。