App Engine 中跨实体组的唯一短标识符
我四处寻找这个问题的答案，但没有找到任何关于金钱的东西。我真的很想听听人们的想法。如下：
在 Google AppEngine 中，假设我有许多 User 对象，每个对象都可以有许多 Photo 对象。 User 对象需要是其各自 Photo 对象的父对象。
但我也希望能够为每张照片提供漂亮的短网址。我打算通过对每张照片自动生成的 ID 属性进行 Base64 编码来生成这些内容，但我意识到我不能这样做，因为 AppEngine 生成的 ID 不能保证在实体组之间是唯一的（即对于具有不同父级的实体）。因此，作为一个用户的子级的照片可能与作为不同用户的子级的照片具有相同的 ID。
这让我陷入困境。我可以：
尝试想出我自己的唯一 ID 生成器并使用它
丢失父子层次结构，以便 ID将是唯一的（根本不热衷于此）
建议使用一些超级聪明的选项作为对此的答案问题
我真的希望选择 3。
任何关于解决这个问题的最佳方法的想法或想法都很棒。
提前致谢。
编辑
发布后，我有了将迷你 URL 缩短服务合并到应用程序中的想法。我只需要一个没有父级的模型和一个指向我想要链接的照片的“Key”属性。然后我可以对这个实体的 Id 进行 Base64 编码，这样就完成了。你怎么认为？
I've searched around for answers to this question, but not found anything quite on the money. I'd be really interested to hear people's thoughts. Here goes:
In Google AppEngine, lets say I have a number of User objects, each of which can have a number of Photo objects. The User objects need to be parents of their respective Photo objects.
But I also want to be able to have nice short urls for each Photo. I intended to generate these by Base64 encoding the automatically generated ID property of each Photo, but I realise I cannot do this as the IDs AppEngine generates are not guaranteed to be unique across entity groups (i.e. for entities with different parents). So a Photo which is a child of one User could conceivably have the same ID as a Photo which is the child of a different User.
This leaves me in a pickle. I can either:
Try to come up with my own unique ID generator and use that
Lose the parent->child hierarchy so IDs will be unique (not keen on this at all)
Some super-clever option suggested as an answer to this question
I'm really hoping for option 3.
Any thoughts or ideas on the best way to deal with this would be fantastic.
Thanks in advance.
Edit
Just after posting I had the idea of incorporating a mini URL shortening service into the app. I'd just need a model with no parent and a single 'Key' property which would point to the Photo I wanted to link to. Then I can Base64 encode the Id of this entity and I'm done. What do you think?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
为什么不直接将父用户的 ID 与相关照片的 ID 一起编码呢？您可以将其编码为两个整数 -
/123/2或您希望的任何其他格式，例如您建议的 base64。如果您让用户选择某种唯一的名称并将其用作用户对象的键名称，那么从 UI 的角度来看，这也更有用，因为它为您提供了类似/photos/nick/123 的 URLWhy not just encode the ID of the parent user along with the ID of the relevant photo? You can encode it as two integers -
/123/2or in any other format you wish, such as base64 as you suggest. If you let users pick a unique name of some sort and use that as the key name on the user object, this is also more useful from a UI point of view, since it gives you URLs like/photos/nick/123如果你能摆脱第 2 个想法——你就完成了。然后您就获得了密钥 - 并且“URL 缩短服务”是一个 3-4 行的 servlet，您就完成了。
但！
你必须付出代价——你无法进行任何交易。
由于 AppEngine 仅支持实体组内部的事务。这实际上会回击您后来基于另一种带有密钥的模型的“URL缩短服务”的想法...
问题是您将无法在管理“用户照片”的同一事务中管理它，因此您最终可能会得到错误的 URL。
如果您必须进行事务 - 从父键中构建一个 url。如果不是 - 使用直接唯一键，没有父->子层次结构。
If you can get away with the idea number 2 - you are done. as then you got your key - and "URL shortening service" is a single servlet of 3-4 lines and you are done.
But!
I you got to pay a price - no transactions for you.
As AppEngine support transactions only inside an entity group. this actually fires back on your later idea of "URL shortening service" based on another model with a key...
The catch is you will not be able to manage it in the same transaction you manage your "photos of the user" so you can end up with wrong URLs.
If you must have transaction - build a url out of the parent keys. if not - use direct unique key with no parent->child hierarchy.