Lithium PHP GridFS 图像读取失败答案

【问题标题】：Lithium PHP GridFS image read failuresLithium PHP GridFS 图像读取失败
【发布时间】：2013-05-23 19:44:34
【问题描述】：

在尝试使用 1.3.4 驱动程序和 Lithium PHP framework 从 MongoDB GridFS 集合中获取图像时，我得到了损坏的图像。我无法确定何时开始发生这种情况，因为尽管相关站点尚未上线，但在每次更改后我都没有对整个站点进行冒烟测试，而且我的测试用例都没有失败（我认为有人更擅长创建 php 测试用例比我可能会告诉我如何在阅读后为此创建测试用例）。

图像实际上在不久前正确渲染。我正在使用 MongoHQ，一个基于云的数据库，mongodb 版本 2.4.1。

当我对通过网络应用程序获取的图像执行 wget 十六进制转储时，我得到以下信息。

0000000 0a ff d8 ff e1 0f fe 45 78 69 66 00 00 4d 4d 00
0000010 2a 00 00 00 08 00 0a 01 0f 00 02 00 00 00 06 00
0000020 00 00 86 01 10 00 02 00 00 00 0a 00 00 00 8c 01
0000030 12 00 03 00 00 00 01 00 08 00 00 01 1a 00 05 00
0000040 00 00 01 00 00 00 96 01 1b 00 05 00 00 00 01 00
0000050 00 00 9e 01 28 00 03 00 00 00 01 00 02 00 00 01
0000060 31 00 02 00 00 00 06 00 00 00 a6 01 32 00 02 00
0000070 00 00 14 00 00 00 ac 02 13 00 03 00 00 00 01 00
0000080 01 00 00 87 69 00 04 00 00 00 01 00 00 00 c0 00
0000090 00 00 00 41 70 70 6c 65 00 69 50 68 6f 6e 65 20

但是当我对静态文件（不是从数据库中获取）执行 wget 时，我得到了这个：

0000000 ff d8 ff e1 0f fe 45 78 69 66 00 00 4d 4d 00 2a
0000010 00 00 00 08 00 0a 01 0f 00 02 00 00 00 06 00 00
0000020 00 86 01 10 00 02 00 00 00 0a 00 00 00 8c 01 12
0000030 00 03 00 00 00 01 00 08 00 00 01 1a 00 05 00 00
0000040 00 01 00 00 00 96 01 1b 00 05 00 00 00 01 00 00
0000050 00 9e 01 28 00 03 00 00 00 01 00 02 00 00 01 31
0000060 00 02 00 00 00 06 00 00 00 a6 01 32 00 02 00 00
0000070 00 14 00 00 00 ac 02 13 00 03 00 00 00 01 00 01
0000080 00 00 87 69 00 04 00 00 00 01 00 00 00 c0 00 00
0000090 00 00 41 70 70 6c 65 00 69 50 68 6f 6e 65 20 34

差异在开头是前导“0a”，最后是“34”。

我正在获取相关的 fs.files 数据。例如：

{
  _id: ObjectId("519e31d39bdd497903000007"),
  tags: [
    "mancave"
  ],
  location: [],
  title: "Test Live Site",
  description: "This is for testing the live site",
  credit: "Test",
  user_name: "chuckwh",
  filename: "dog.jpg",
  uploadDate: ISODate("2013-05-23T15:12:19.000Z"),
  length: 86486,
  chunkSize: 262144,
  md5: "88d87a79a98106502777d06a4c7db329"
}

而且，很明显，十六进制转储表明我基本上也得到了图像，只是看起来我得到了它的损坏版本。我的堆栈跟踪中没有任何信息表明存在问题。

我注意到 Lithium 开发人员在他们的 Mongo DB 中添加了一个补丁来更好地处理前缀，但无论如何我并没有做任何棘手的事情，只是检索 fs.files，没有潜在的命名空间问题。

由于它以前有效，我怀疑是 php 驱动程序问题，但我没有看到任何通过 Google 或此处讨论的已知问题。有人知道涉及 mongodb 2.4.1 版、GridFS 和 1.3.4 驱动程序的任何 php 驱动程序问题吗？

就代码而言，我几乎是按照这里的方式来做的：

https://github.com/nateabele/photoblog/blob/master/controllers/PhotosController.php

该链接中的控制器引用了一个模型，该模型包含一个或两个锂库，但核心锂包不附带，例如行为，但我再次强调，直到最近它才有效。该网站的这一部分与该网站的其他部分非常隔离。我所做的唯一路由更改是添加了一些分页，但我对此进行了评论，但仍然出现错误。我希望这个问题是“格式良好的”。我想我正在寻找的是，而不是一个特定的解决方案，一些关于我应该在哪里寻找的指针，因为到目前为止我显然没有在正确的地方寻找。谢谢

【问题讨论】：

读取图像的代码呢？你注意到github.com/nateabele/photoblog/blob/master/config/bootstrap/…了吗？
谢谢，Nate - 是的，我使用了确切的路线 - 正如我所提到的，它直到最近都运行良好。我的 mongo 提供商同意我的观点，这可能是驱动程序问题。我还没有机会为此在 IP 上运行 mongo shell，但我会尽快更新这篇文章。再次感谢。

标签： php mongodb gridfs lithium

【解决方案1】：

自 1.3.4 以来，GridFS 组件没有任何重大变化（请参阅：changelog）。要调查的一件事是直接从fs.chunks 读取数据。

由于您在上面共享的 fs.files 文档的整个图像只有 86486 字节并且块大小为 262144，因此我们可以预期它会完全包含在第一个块中。搜索files_id 字段为ObjectId("519e31d39bdd497903000007") 的fs.chunks 集合应该会找到单个文档。有关该集合架构的更多详细信息，请参见 here。

需要注意的一点是，MD5 哈希是由服务器在最初存储文件时计算的。因此，上面文档中的哈希值应该与块的 data 字段的哈希值匹配。如果这些值不同，则集合可能在事后被修改。内存/网络损坏也可能在起作用。在 PHP 驱动程序中读取文件的逻辑只是连接来自fs.chunks 查询的字段，因此不太可能存在测试套件尚未发现的突出错误。

【讨论】：