doukun8670 2013-08-10 00:56
浏览 6
已采纳

具有新字段/属性的投影查询将忽略尚未设置这些属性的条目

I have an Article type structured like this:

type Article struct {
    Title    string
    Content  string `datastore:",noindex"`
}

In an administrative portion of my site, I list all of my Articles. The only property I need in order to display this list is Title; grabbing the content of the article seems wasteful. So I use a projection query:

q := datastore.NewQuery("Article").Project("Title")

Everything works as expected so far. Now I decide I'd like to add two fields to Article so that some articles can be unlisted in the public article list and/or unviewable when access is attempted. Understanding the datastore to be schema-less, I think this might be very simple. I add the two new fields to Article:

type Article struct {
    Title    string
    Content  string `datastore:",noindex"`

    Unlisted   bool
    Unviewable bool
}

I also add them to the projection query, since I want to indicate in the administrative article list when an article is publicly unlisted and/or unviewable:

q := datastore.NewQuery("Article").Project("Title", "Unlisted", "Unviewable")

Unfortunately, this only returns entries that have explicitly included Unlisted and Unviewable when Put into the datastore.

My workaround for now is to simply stop using a projection query:

q := datastore.NewQuery("Article")

All entries are returned, and the entries that never set Unlisted or Unviewable have them set to their zero value as expected. The downside is that the article content is being passed around needlessly.

In this case, that compromise isn't terrible, but I expect similar situations to arise in the future, and it could be a big deal not being able to use projection queries. Projections queries and adding new properties to datastore entries seem like they're not fitting together well. I want to make sure I'm not misunderstanding something or missing the correct way to do things.

  1. It's not clear to me from the documentation that projection queries should behave this way (ignoring entries that don't have the projected properties rather than including them with zero values). Is this the intended behavior?

  2. Are the only options in scenarios like this (adding new fields to structs / properties to entries) to either forgo projection queries or run some kind of "schema migration", Getting all entries and then Puting them back, so they now have zero-valued properties and can be projected?

  • 写回答

1条回答 默认 最新

  • dongtuo7364 2013-08-10 01:51
    关注

    Projection queries source the data for fields from the indexes not the entity, when you have added new properties pre-existing records do not appear in those indexes you are performing the project query on. They will need to be re-indexed.

    You are asking for those specific properties and they don't exist hence the current behaviour.

    You should probably think of a projection query as a request for entities with a value in a requested index in addition to any filter you place on a query.

    本回答被题主选为最佳回答 , 对您是否有帮助呢?
    评论

报告相同问题?

悬赏问题

  • ¥15 本题的答案是不是有问题
  • ¥15 关于#r语言#的问题:(svydesign)为什么在一个大的数据集中抽取了一个小数据集
  • ¥15 C++使用Gunplot
  • ¥15 这个电路是如何实现路灯控制器的,原理是什么,怎么求解灯亮起后熄灭的时间如图?
  • ¥15 matlab数字图像处理频率域滤波
  • ¥15 在abaqus做了二维正交切削模型,给刀具添加了超声振动条件后输出切削力为什么比普通切削增大这么多
  • ¥15 ELGamal和paillier计算效率谁快?
  • ¥15 蓝桥杯单片机第十三届第一场,整点继电器吸合,5s后断开出现了问题
  • ¥15 file converter 转换格式失败 报错 Error marking filters as finished,如何解决?
  • ¥15 Arcgis相交分析无法绘制一个或多个图形