从外部源自动更新谷歌应用程序引擎数据存储的最佳方法？
我读过“Google App Engine 数据存储区和外部的最佳选择”数据库”，并且我已经考虑过 SDC（我们已经将它用于某些事情）。但是，我需要能够每 15 分钟左右自动更新一次数据存储。在 AppEngine 中使用 cronjob 时，没有用户附加到操作，因此它无法向 SDC 进行身份验证。请注意，外部数据库位于防火墙后面（如果上面的 SDC 语句不明显的话）。
有没有办法让 SDC 执行某种预定+自动操作？如果没有，推荐的替代方案是什么？
I read "Best option for Google App Engine Datastore and external database", and I had already considered the SDC(we already use it for some things). However, I need to be able to automate the update of the datastore every 15 minutes or so. When using a cronjob in AppEngine there is no user attached to the actions, therefore it can't authenticate to the SDC. Note that the external DB is behind a firewall(if it wasn't obvious by the SDC statement above).
Is there a way to get the SDC to work with some sort of scheduled+automated action? If not, what would be the recommended alternative?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
我知道回答你自己的问题有点愚蠢，但我想我也可以发布我的解决方案，因为这里没有答案。
尼克留下的评论绝对是解决问题的一种选择，但我发现更容易并且在当前情况下有效的是将数据推出，而不是担心通过身份验证保护防火墙中的接入点。
我使用远程 API 并创建了一个位于防火墙后面的 Python 应用程序。在计划的 cron 中，我从 SQL Server 查询数据，从应用程序的数据存储中查询数据，然后添加/更新/删除数据存储，仅包含自上次运行应用程序以来更改的内容。此时，我将数据推送回数据存储区。为了提高效率，您也可以将其设置为批量推送（如数据存储文档中所述）。
该解决方案适用于当前的应用程序，但我绝对可以看到设置带有身份验证的 RESTful 服务，以应对这不是最佳攻击计划的情况。
I know it's kinda silly to answer your own question, but figured I may as well post my solution since there is no answer here.
What Nick left a comment about is definitely one option for solving the the problem, but what I found to be easier, and will work in the current situation is to push the data out rather than worry about securing an access point in the firewall with authentication.
I used the Remote API and created a Python application that will sit behind the firewall. On a scheduled cron, I query the data from SQL Server, query the data from the datastore for the app, and then add/update/delete the datastore with only the things that changed since the last run of the app. At this point I then push the data back up to the Datastore. For efficiency you can set it up to push out in batches as well(as is preached through the Datastore documentation).
This solution will work for the current app, but I could definitely see setting up a RESTful service with authentication for situations that this wouldn't be the best plan of attack.