【问题标题】:Unique short identifier across entity groups in App EngineApp Engine 中跨实体组的唯一短标识符
【发布时间】:2011-06-25 09:39:09
【问题描述】:

我已经四处寻找这个问题的答案,但没有找到任何物有所值的东西。我真的很想听听人们的想法。如下:

在 Google AppEngine 中,假设我有多个 User 对象,每个对象都可以有多个 Photo 对象。 User 对象需要是其各自 Photo 对象的父对象。

但我也希望能够为每张照片提供漂亮的短网址。我打算通过 Base64 编码每张照片的自动生成的 ID 属性来生成这些,但我意识到我不能这样做,因为 AppEngine 生成的 ID 不能保证在实体组之间是唯一的(即对于具有不同父级的实体)。因此,可以想象作为一个用户的孩子的照片与作为不同用户的孩子的照片具有相同的 ID。

这让我陷入困境。我可以:

  1. 尝试想出我自己的唯一 ID 生成器并使用它

  2. 失去父->子层次结构,因此 ID 将是唯一的(根本不热衷于此)

  3. 建议使用一些超级聪明的选项来回答这个问题

我真的希望选项 3。

任何关于解决此问题的最佳方法的想法或想法都很棒。

提前致谢。

编辑

刚发布后,我就有了将迷你 URL 缩短服务整合到应用程序中的想法。我只需要一个没有父级的模型和一个指向我想要链接的照片的“键”属性。然后我可以对这个实体的 ID 进行 Base64 编码,我就完成了。你怎么看?

【问题讨论】:

    标签: google-app-engine google-cloud-datastore entity-groups


    【解决方案1】:

    为什么不将父用户的 ID 与相关照片的 ID 一起编码呢?您可以将其编码为两个整数 - /123/2 或您希望的任何其他格式,例如您建议的 base64。如果您让用户选择某种唯一名称并将其用作用户对象上的键名,那么从 UI 的角度来看,这也更有用,因为它为您提供了类似 /photos/nick/123 的 URL

    【讨论】:

    • 感谢尼克的回复。这是一个好主意,但在现实生活中的层次结构比我在问题中给出的示例要深一些,所以 URL 会有几个部分,最终可能会很长。不过,这绝对是一种可能性。
    • @Mason 好吧,同样的推理仍然适用 - 编码的 ID 列表总是比整个编码的密钥短得多。
    • 确实如此,我认为您的建议目前看起来很不错。您如何看待 URL 缩短服务理念? Boris(下)提到了关于交易的保留,但我看不出问题出在哪里。你能?在此先感谢,我是 GAE 的新手,我经常觉得我现在正在和 DB 下棋!
    • 万一其他人处于相同的位置,我就是这样做的,我对此非常满意。
    【解决方案2】:

    如果你能摆脱第 2 个想法 - 你就完成了。然后你得到了你的密钥——“URL 缩短服务”是一个 3-4 行的单个 servlet,你就完成了。

    但是!

    你必须付出代价 - 没有交易为你。

    因为 AppEngine 仅支持实体组内的事务。这实际上回击了您后来基于另一个带有密钥的模型的“URL 缩短服务”的想法......

    问题是您将无法在管理“用户照片”的同一事务中管理它,因此您最终可能会得到错误的 URL。

    如果您必须进行交易 - 从父键构建一个 url。如果不是 - 使用没有父->子层次结构的直接唯一键。

    【讨论】:

    • 谢谢鲍里斯。你能解释一下为什么 URL 缩短服务不能更详细地工作吗?在我看来,如果我先做 Photo.get_or_insert() 然后再做 ShortURL.get_or_insert(str(photo.key())) 那么我总会得到我想要的。然后,当我解释像 mydomain.com/1023 这样的 url 时,我会查找具有该 ID 的 ShortURL 并找到键名指向的实体。这是错的吗?
    • 好吧,只要一切正常,它就会工作,但是按照您描述的方式,您对事务中的实体执行操作,然后创建/更新作为 URL 缩短事务的指针的实体,以便它可以碰巧事务中的数据也可以,引用会出错。
    猜你喜欢
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2021-02-26
    • 1970-01-01
    • 1970-01-01
    • 2016-07-23
    • 1970-01-01
    • 1970-01-01
    相关资源
    最近更新 更多