当前位置： 文江博客话题详情

有关 Google App Engine 查询和日期时间的帮助

发布于 2024-07-16 12:28:17 字数 3434 浏览 5 评论 0原文

我使用以下数据：

date                     latitude         route      name   longitude
2009-04-11 00:50:31.640000  40.80708    White Loop  86  -77.85891
2009-04-11 00:50:27.718000  40.80708    White Loop  86  -77.85891
2009-04-11 00:50:01.562000  40.80708    White Loop  86  -77.85891
2009-04-11 00:49:48.765000  40.80708    White Loop  86  -77.85891
2009-04-11 00:49:34.796000  40.802338   White Loop  86  -77.85073
2009-04-11 00:49:22.468000  40.802338   White Loop  86  -77.85073
2009-04-11 00:48:35.671000  40.802338   White Loop  86  -77.85073
2009-04-11 00:48:29.125000  40.802338   White Loop  86  -77.85073
2009-04-11 00:47:19.906000  40.79889    White Loop  86  -77.85299
2009-04-11 00:47:03.609000  40.79889    White Loop  86  -77.85299
2009-04-11 00:46:54.437000  40.79889    White Loop  86  -77.85299
2009-04-11 00:46:52.687000  40.79889    White Loop  86  -77.85299
2009-04-11 00:46:51.125000  40.79889    White Loop  86  -77.85299
2009-04-11 00:46:48.578000  40.79889    White Loop  86  -77.85299
2009-04-11 00:46:41.406000  40.79889    White Loop  86  -77.85299
2009-04-11 00:50:31.687000  40.792194   White Loop  82  -77.863235
2009-04-11 00:50:27.781000  40.792194   White Loop  82  -77.863235
2009-04-11 00:50:01.640000  40.792194   White Loop  82  -77.863235
2009-04-11 00:49:48.812000  40.792194   White Loop  82  -77.863235
2009-04-11 00:49:34.843000  40.794914   White Loop  82  -77.866844
2009-04-11 00:49:22.531000  40.794914   White Loop  82  -77.866844
2009-04-11 00:48:35.718000  40.794914   White Loop  82  -77.866844
2009-04-11 00:48:29.156000  40.79738    White Loop  82  -77.86755
2009-04-11 00:47:19.984000  40.79738    White Loop  82  -77.86755
2009-04-11 00:47:03.656000  40.79738    White Loop  82  -77.86755
2009-04-11 00:46:54.484000  40.79738    White Loop  82  -77.86755
2009-04-11 00:46:52.734000  40.79738    White Loop  82  -77.86755
2009-04-11 00:46:51.156000  40.79738    White Loop  82  -77.86755
2009-04-11 00:46:48.640000  40.79738    White Loop  82  -77.86755
2009-04-11 00:46:41.453000  40.79738    White Loop  82  -77.86755
2009-04-11 00:50:31.656000  40.776066   White Loop  81  -77.88552
2009-04-11 00:50:27.750000  40.776066   White Loop  81  -77.88552
2009-04-11 00:50:01.593000  40.776066   White Loop  81  -77.88552
2009-04-11 00:49:48.796000  40.776066   White Loop  81  -77.88552
2009-04-11 00:49:34.812000  40.764687   White Loop  81  -77.88271
2009-04-11 00:49:22.515000  40.764687   White Loop  81  -77.88271
2009-04-11 00:48:35.703000  40.764687   White Loop  81  -77.88271
2009-04-11 00:48:29.140000  40.764687   White Loop  81  -77.88271
2009-04-11 00:47:19.937000  40.76335    White Loop  81  -77.876755
2009-04-11 00:47:03.640000  40.76335    White Loop  81  -77.876755
2009-04-11 00:46:54.468000  40.76335    White Loop  81  -77.876755
2009-04-11 00:46:52.718000  40.76335    White Loop  81  -77.876755
2009-04-11 00:46:51.156000  40.76335    White Loop  81  -77.876755
2009-04-11 00:46:48.609000  40.76335    White Loop  81  -77.876755
2009-04-11 00:46:41.437000  40.76335    White Loop  81  -77.876755

如何优化查询以仅获取每个“名称”的最新行？ 例如，我只想最终得到：

2009-04-11 00:50:31.640000  40.80708    White Loop  86  -77.85891
2009-04-11 00:50:31.687000  40.792194   White Loop  82  -77.863235
2009-04-11 00:50:31.656000  40.776066   White Loop  81  -77.88552

并且我希望所有结果的日期值不超过 1 分钟。 请记住，日期值是 Python 日期时间属性。

谢谢

原文

I use the following data:

date                     latitude         route      name   longitude
2009-04-11 00:50:31.640000  40.80708    White Loop  86  -77.85891
2009-04-11 00:50:27.718000  40.80708    White Loop  86  -77.85891
2009-04-11 00:50:01.562000  40.80708    White Loop  86  -77.85891
2009-04-11 00:49:48.765000  40.80708    White Loop  86  -77.85891
2009-04-11 00:49:34.796000  40.802338   White Loop  86  -77.85073
2009-04-11 00:49:22.468000  40.802338   White Loop  86  -77.85073
2009-04-11 00:48:35.671000  40.802338   White Loop  86  -77.85073
2009-04-11 00:48:29.125000  40.802338   White Loop  86  -77.85073
2009-04-11 00:47:19.906000  40.79889    White Loop  86  -77.85299
2009-04-11 00:47:03.609000  40.79889    White Loop  86  -77.85299
2009-04-11 00:46:54.437000  40.79889    White Loop  86  -77.85299
2009-04-11 00:46:52.687000  40.79889    White Loop  86  -77.85299
2009-04-11 00:46:51.125000  40.79889    White Loop  86  -77.85299
2009-04-11 00:46:48.578000  40.79889    White Loop  86  -77.85299
2009-04-11 00:46:41.406000  40.79889    White Loop  86  -77.85299
2009-04-11 00:50:31.687000  40.792194   White Loop  82  -77.863235
2009-04-11 00:50:27.781000  40.792194   White Loop  82  -77.863235
2009-04-11 00:50:01.640000  40.792194   White Loop  82  -77.863235
2009-04-11 00:49:48.812000  40.792194   White Loop  82  -77.863235
2009-04-11 00:49:34.843000  40.794914   White Loop  82  -77.866844
2009-04-11 00:49:22.531000  40.794914   White Loop  82  -77.866844
2009-04-11 00:48:35.718000  40.794914   White Loop  82  -77.866844
2009-04-11 00:48:29.156000  40.79738    White Loop  82  -77.86755
2009-04-11 00:47:19.984000  40.79738    White Loop  82  -77.86755
2009-04-11 00:47:03.656000  40.79738    White Loop  82  -77.86755
2009-04-11 00:46:54.484000  40.79738    White Loop  82  -77.86755
2009-04-11 00:46:52.734000  40.79738    White Loop  82  -77.86755
2009-04-11 00:46:51.156000  40.79738    White Loop  82  -77.86755
2009-04-11 00:46:48.640000  40.79738    White Loop  82  -77.86755
2009-04-11 00:46:41.453000  40.79738    White Loop  82  -77.86755
2009-04-11 00:50:31.656000  40.776066   White Loop  81  -77.88552
2009-04-11 00:50:27.750000  40.776066   White Loop  81  -77.88552
2009-04-11 00:50:01.593000  40.776066   White Loop  81  -77.88552
2009-04-11 00:49:48.796000  40.776066   White Loop  81  -77.88552
2009-04-11 00:49:34.812000  40.764687   White Loop  81  -77.88271
2009-04-11 00:49:22.515000  40.764687   White Loop  81  -77.88271
2009-04-11 00:48:35.703000  40.764687   White Loop  81  -77.88271
2009-04-11 00:48:29.140000  40.764687   White Loop  81  -77.88271
2009-04-11 00:47:19.937000  40.76335    White Loop  81  -77.876755
2009-04-11 00:47:03.640000  40.76335    White Loop  81  -77.876755
2009-04-11 00:46:54.468000  40.76335    White Loop  81  -77.876755
2009-04-11 00:46:52.718000  40.76335    White Loop  81  -77.876755
2009-04-11 00:46:51.156000  40.76335    White Loop  81  -77.876755
2009-04-11 00:46:48.609000  40.76335    White Loop  81  -77.876755
2009-04-11 00:46:41.437000  40.76335    White Loop  81  -77.876755

How can I refine the query to get only the most recent rows for each "name"? For example, I only want to end up with:

2009-04-11 00:50:31.640000  40.80708    White Loop  86  -77.85891
2009-04-11 00:50:31.687000  40.792194   White Loop  82  -77.863235
2009-04-11 00:50:31.656000  40.776066   White Loop  81  -77.88552

And I want all results to have date values that are no more than 1 minute old. Keep in mind that the date values are Python datetime properties.

Thanks

如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论， 你可以免费 注册 一个本站的账号。

评论（3）

活雷疯 2024-07-23 12:28:17

在 SQL 中你可以做各种奇特的事情，但 Google API 相当有限。

假设您希望所有记录不超过 1 分钟，我只需向数据库询问所有不超过 1 分钟的记录，然后让 python 整理结果并拒绝重复的行。

从您在此处显示的数据来看，您似乎每分钟左右每个“名称”都会获得几行，因此这种方法应该足够了，尽管它不太优雅。

另一种方法是保留第二个表，其中仅包含每个“名称”的最新条目……并时不时地剔除该表以删除超过一分钟的记录。

In SQL you could do all sorts of fancy things, but Google API is rather limited.

Given that you want all records to be no more than 1 minute old, I'd just ask the database for all records less than 1 minute old, and then have python collate the results and reject the duplicate rows.

From the data you show here, it looks like you're getting a couple of rows per 'name' per minute or so, so that approach should be sufficient even though its inelegant.

The alternative would be to keep a second table with only the latest entry for each 'name' in it ... and cull that table every now and then to remove records over a minute old.

回复 原文
奢华的一滴泪 2024-07-23 12:28:17

我想我找到了一个不错的解决方案。 问题出在我的模型中：

date = db.DateTimeProperty(auto_now_add=True)

这意味着对于该模型的每个实例，日期时间都会略有不同。 这使得对我的数据进行分组非常困难。 因此，在我的 cron 函数中，我确保每个 api 请求都有完全相同的时间戳。

下一个更改是创建一个 Current 表。 每次 cron 运行时，它都会删除当前表中的所有内容（仅一行），并添加一个新行。 然后，这个新行被添加到半永久存储结果的日志表中。

I think I figured out a decent solution. The problem was in my model:

date = db.DateTimeProperty(auto_now_add=True)

This meant that for every instance of that model, the datetimes would all be slightly different. This makes grouping my data very difficult. So in my cron function, I made sure that every api request had the exact same time stamp.

The next change was to create a Current table. Every time the cron runs, it deletes everything in the Current table (only one row), and adds a new row. This new row is then added to a Log table which semi-permanently stores the results.

回复 原文
听不够的曲调 2024-07-23 12:28:17

这当然可行：

query = db.GqlQuery("SELECT * FROM [table] ORDER BY date DESC LIMIT BY [num of rows]")

或者，您可以使用不等式，例如“date > 2009-04-11 00:50”，它将返回该时间之后的所有结果。

Surely this would work:

query = db.GqlQuery("SELECT * FROM [table] ORDER BY date DESC LIMIT BY [num of rows]")

Alternatively, you could use an inequality, like "date > 2009-04-11 00:50", which would return all the results after that time.

回复 原文
~没有更多了~

关于作者

终遇你

暂无简介

0 文章
0 评论
686 人气
发私信

相关话题

更多

热门标签

操作系统 程序设计 IT运维 Linux系统管理 JavaScript 服务器应用 solaris C/C++ PHP Shell BSD Vue.js aix Oracle Python HTML 系统管理 HTML5 CSS 前端
更多

推荐作者

1CH1MKgiKxn9p

文章 0 评论 0

ゞ记忆︶ㄣ

文章 0 评论 0

JackDx

文章 0 评论 0

信远

文章 0 评论 0

yaoduoduo1995

文章 0 评论 0

霞映澄塘

文章 0 评论 0

更多

友情链接

文江博客
    我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站，即表示您同意使用 Cookies 和您的相关数据。
    原文