Mongo-go-driver GridFS 元数据

大家好，我们又见面了啊~本文《MonGo-go-driver GridFS 元数据》的内容中将会涉及到等等。如果你正在学习golang相关知识，欢迎关注我，以后会给大家带来更多Golang相关文章，希望我们能一起进步！下面就开始本文的正式内容~

我为我工作的公司编写了一个聊天应用程序，并且我与 mgo 驱动程序一起工作了一段时间。 现在我们将 mgo 重构为官方 mongo 驱动程序。 我已经实现了 gridfs 来处理聊天文件，因为它们并不大，而且它简化了工作。 以前的 mgo 驱动程序在保存文件时有一个数据列表，其中一个字段是 contenttype（很好，对吧？）

因此，在重构此任务中包含的大部分服务后，我注意到新的官方 mongo 驱动程序不会执行此操作？

所以我决定尝试手动添加此字段，但后来我发现我不明白该怎么做？

尝试过 options.gridfsupload().setmetadata(metadata) 但我不明白它的逻辑，而且互联网对于在 go 中工作的新 mongo 驱动程序的结果来说确实很小。

任何人都可以给我提示如何将自定义字段添加到文件文档吗？ 喜欢内容类型！！

非常感谢。

这是我尝试做的一个例子

// GridFSInsert -
func GridFSInsert(fileName string, data []byte, metadata ...bsonx.Elem) (primitive.ObjectID, error) {
    checkMongoConnection(false)
    var fileID primitive.ObjectID
    bucket, bucketErr := gridFs.NewBucket(
        Mongo.Client.Database(Mongo.DBName),
        options.GridFSBucket().SetName(gridFSColName),
    )
    if bucketErr != nil {
        return fileID, bucketErr
    }
    uploadStream, uploadStreamErr := bucket.OpenUploadStream(
        fileName,
        options.GridFSUpload().SetMetadata(metadata),
    )
    if uploadStreamErr != nil {
        return fileID, uploadStreamErr
    }
    defer uploadStream.Close()

    fileSize, writeErr := uploadStream.Write(data)
    if writeErr != nil {
        return fileID, writeErr
    }
    fileID = uploadStream.FileID
    log.Printf("Write file to DB was succesful, File size: %d", fileSize)

    return fileID, nil
}

很抱歉，如果我错过了一些东西，因为我对 go 的经验并不如我所愿。

感谢您的帮助

解决方案

没有您想要理解的逻辑。之所以在新的官方mongo驱动中找不到太多关于contenttype的信息，是因为contentType has been deprecated in gridfs spec早在驱动编写之前就已经存在了。

我必须承认gridfs documentation没有提到它。事实上官方 mongofiles cli 仍然使用旧格式。

规范说得很清楚：

注意：某些旧版本的 gridfs 实现允许应用程序向根级别的文件集合文档添加任意字段。 gridfs 的新实现不允许这样做，但必须准备好处理可能具有其他字段的现有文件集合文档。

如果您喜欢更详细的信息official reasoning：

为什么 contenttype 被弃用？

文件集合文档中的大多数字段都由驱动程序直接使用，但元数据、contenttype 和别名除外。所有纯粹用于应用程序的信息都应嵌入“元数据”文档中。我们鼓励想要存储 contenttype 以在其应用程序中使用的 gridfs 用户将“contenttype”字段添加到“元数据”文档，而不是使用已弃用的顶级“contenttype”字段。

这有点道理。驱动程序从字面上遵循规范的措辞 - 除了 metadata 之外，无法在任何地方创建 contenttype 属性，但 bucket.find 仍将返回由“旧版本”创建的文件的 contenttype 。

从旧版 gridfs 到新格式的一次性转换可以非常简单：

db.getcollection("fs.files").aggregate([
    {$addfields: { 
        "length" : {$tolong: "$length"},
        "metadata.contenttype": { $ifnull: [ "$contenttype", "$metadata.contenttype" ] } 
    }},
    { $out : "fs.files" }
])

假设您的存储桶是默认的“fs”，并且您不打算上传旧格式的文件。 如果您有足够的可用空间，那么 out 到新的临时集合，验证它，然后重命名并不是一个糟糕的主意。

如果您出于任何原因必须支持旧格式，您仍然可以直接访问 gridfs 集合：

// in your code snippet after
fileid = uploadstream.fileid

// update the document that represent uploaded file
files := db.collection("fs.files")
updateresult, err := files.updateone(
    context.background(),
    bson.d{{"_id", fileid}},
    bson.d{{"$set", bson.d{{"contenttype", contenttype}}}},
)

其中“fs”是您的存储桶名称，contenttype 是您要设置为 contenttype 的字符串值。

请记住，“某些旧版本”使用 int32 作为文件长度。新驱动程序期望它是 int64。 对于单独使用 *.fiiles 集合的类似 find 的操作应该没问题，但可能会导致使用新的官方驱动程序下载此类文件时出现问题。

这里是 setmetadata() 的示例。

opts := options.GridFSUpload()
opts.SetMetadata(bsonx.Doc{{Key: "content-type", Value: bsonx.String("application/JSON")}})
if ustream, err = bucket.OpenUploadStream("test.txt", opts); err != nil {
    t.Fatal(err)
}

这是 full example

今天关于《Mongo-go-driver GridFS 元数据》的内容介绍就到此结束，如果有什么疑问或者建议，可以在编程网公众号下多多回复交流；文中若有不正之处，也希望回复留言以告知！