Happstack-state 概念和文档？
我开始制作 Haskell Web 服务器。我决定从 Happstack 和 Happstack-state 开始。我感觉很难理解 Happstack-state 的概念和属性。它是一种新型数据库吗？或者只是像系统一样的对象图？
你能解释一下它的概念和属性（特别是关于ACID，它如何在磁盘上持久化数据！）或者给我一个很好地描述它的文档吗？
I'm starting making Haskell web server. I've decided to start with Happstack and Happstack-state. And I'm feeling hard to understand concept and attribute of Happstack-state. Is it a new kind of database? or Just object-graph like system?
Can you explain it's concept and attribute (especially about ACID, how it persistent data on disk!) or point me a document describes it well?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
以下是 MACID 的两个基本介绍：
http://happstack.com/docs/crashcourse/HappstackState .html#happstack_state
http:// www.kuliniewicz.org/blog/archives/2009/04/05/happstackstate-the-basics/
唉，两者都没有涵盖 IxSet，这是一种经常与 MACID 一起使用的数据类型，以提供具有多个索引的集合（类似到 SQL 表）。
MACID 是“ram 云”样式的持久存储，这意味着您的整个数据集都存储在 RAM 中。目前它支持复制。开发版本的重点是添加分片支持（除其他外）。
MACID 的独特之处在于它存储正常的 Haskell 数据类型，并且查询是使用正常的 Haskell 函数编写的。您不仅限于 Haskell 数据类型的一小部分，例如 Int 和 String。相反，您可以使用几乎任何用户定义的数据类型。
尽管 MACID 将工作数据集存储在 RAM 中并且不是围绕关系模型构建的，但它仍然提供 ACID 保证。持久性属性确保一旦提交成功返回，即使服务器故障（或重新启动），事件也不会丢失。
通过将每个更新事件记录到预写日志中来实现持久性。如果服务器出现故障，可以通过重播自上一个检查点以来的任何事件来恢复状态。
预写日志中的事件由更新函数的名称和该函数的参数组成。由于更新事件是纯粹的，因此重播它们总是会导致相同的最终状态。
检查点或日志事件中存储的数据的实际二进制格式是通过创建 Serialize 类的实例来指定的。在大多数情况下，这可以通过调用 template-haskell 函数“deriveSerialize”自动完成。还有一个 Migrate 类，用于在更改数据类型时将值从旧格式迁移到新格式。
这里有一篇关于序列化和迁移机制的旧博客文章：
http://nhlab.blogspot.com/2008/12/data-migration-with-happs-data.html
这篇文章提到了“HAppS”，但除了模块名称。
希望这有帮助。
Here are two basic introductions to MACID:
http://happstack.com/docs/crashcourse/HappstackState.html#happstack_state
http://www.kuliniewicz.org/blog/archives/2009/04/05/happstackstate-the-basics/
Alas, neither covers IxSet, which is a datatype that is often used with MACID to provide sets with multiple indexes (similar to a SQL table).
MACID is a "ram cloud" style persistent store, meaning your entire dataset is stored in RAM. It currently supports replication. The development version is focused on adding sharding support (among other things).
The thing that makes MACID unique is that it stores normal Haskell dataypes and queries are written using normal Haskell functions. You are not limited to just a small subset of Haskell datatypes such as Int and String. Instead, you can use almost any user defined datatype.
Although MACID stores the working dataset in RAM and is not built around the relational model, it does still provide ACID guarantees. The durability property ensures that once a commit returns successfully, the event will not be lost if their is a server failure (or restart).
Durability is achieved by logging each update event to a write-ahead log. If the the server goes down, the state can be restored by replaying any events since the last checkpoint.
An event in the write-ahead log consists of the name of the update function and the arguments to that function. Since update events are pure, replaying them always results in the same final state.
The actually binary format for the data stored in checkpoints or log events is specified by creating a instance of the Serialize class. In most cases this can be done automatically by calling the template-haskell function 'deriveSerialize'. There is also a Migrate class which is used to migrate values from old formats to new formats when you change your datatypes.
There is an old blog post on the serialization and migration mechanisms here:
http://nhlab.blogspot.com/2008/12/data-migration-with-happs-data.html
That post refers to 'HAppS', but it is pretty much the same in Happstack aside from the module names.
Hope this helps.
MACID 不是数据库，最重要的是它只是一个 ACID 框架，也就是说，它关心事务安全，具体是通过保留磁盘事务日志来实现的。最重要的是，您可以使用例如
IxSet，这是类固醇设置和标准选择，但您同样可以自己推出。恐怕我所知道的最好的文档就是来源本身。 HappStack 的文档非常少。
MACID is not a database, foremost its's just an ACID framework, that is, it cares about transactional safety, precisely by keeping an on-disk transaction log. On top of that, you can use e.g.
IxSet, which are sets on steroids and a standard choice, but you could equally well roll your own.I'm afraid the best documentation I know about is the source, itself. HappStack is whoefully underdocumented.