> 田中さん

> paptimusです。

> 本家で、
> http://code.google.com/p/googleappengine/issues/detail?id=901
> じゃないって言われました。確かに症状は同じです。
> ご推察の通り、putまわりの問題だった可能性が高いですね。

> で、このissueが直っているのはともかく、これまでのデータについては影響下にあるという理解です。
> indexのバキューム、再構築の度にresult setが変わるというの謎ですし。

> とは言え、今は直っているということなので、データを再登録することで様子を見たいと思っています。

> 皆様いろいろとアドバイスありがとうございました。

> On 12月16日, 午後12:12, "kimio tanaka" <kwin...@gmail.com> wrote:
>> > auto_now_addが関係していれば、おっしゃるとおり回避策がありそうですが、
>> > 先にも書きましたが単なるStringPropertyに
>> > indexをはった場合でも起こっており、auto_now_addが原因ではなさそうです。

>> すみません、投稿内容を読んでいたつもりが、   auto_now_add で検索した
>> タイミングで ignore してしまっていました。

>> > 先のdekopinさんに頂いたコメントも考慮し、ソースには全く手を入れず、
>> > 今一度vacuum_index、index生成を繰り返してみました。
>> > その結果、同一queryでの検索件数が異なりましたので、
>> > vacuum_indexを実施後の同一indexの生成に的を絞って調べたいと思っています。

>> index 作成が終わらない問題が多く報告されていますが、これの対応としてhttp://code.google.com/p/googleappengine/issues/detail?id=764
>> timeout などでハングアップしないようにエスケープするようにしたのはいいけれ
>> ども、肝心の index の作成もこの部分はスキップするようになってしまった
>> なんていうことはないと思いますが、いやな現象ですね。

>> 2008/12/16 3:40 paptimus <papti...@gmail.com>:

>> > 田中さん、コメントありがとうございます。

>> >> 特に　issue 612　あたりはどうでしょうか。
>> > 残念ながら私の場合はDataViewerではなく、GAE上でのquery実行時に症状が現れています。

>> > # auto_now_add = True　が「当たり」だとすると、これを使わない Datatime の
>> > # Property を作成して自分で時刻を登録するようにすれば回避できそうですが...
>> > auto_now_addが関係していれば、おっしゃるとおり回避策がありそうですが、先にも書きましたが単なるStringPropertyに
>> > indexをはった場合でも起こっており、auto_now_addが原因ではなさそうです。

>> > 先のdekopinさんに頂いたコメントも考慮し、ソースには全く手を入れず、今一度vacuum_index、index生成を繰り返してみまし
>> > た。
>> > その結果、同一queryでの検索件数が異なりましたので、vacuum_indexを実施後の同一indexの生成に的を絞って調べたいと思っていま
>> > す。

>> > On 12月15日, 午後8:00, "kimio tanaka" <kwin...@gmail.com> wrote:
>> >> issue を　"auto_now_add = True"　で検索してヒットする

>> >>http://code.google.com/p/googleappengine/issues/list?can=2&q=auto_now...

>> >> ものが怪しいのではないかと思われます。
>> >> 特に　issue 612　あたりはどうでしょうか。

>> >>http://code.google.com/p/googleappengine/issues/detail?id=612&can=1&q...

>> >> SDK 環境ですが Data Type が Text　のものを datastore view 経由で編集のため、
>> >> 表示しようとするとエラーとなるようになってしまったことがあり、
>> >> このときの 原因は Data はあるのに Datat Type が Null と
>> >> 認識されていため、ということがありました。

>> >> Google の DataStore は RDBMS でいう
>> >> ところの dictionary は持たないで、データをみながらData　type を識別しているような
>> >> ところあるようなので、このあたりの整合性の齟齬が原因なのではないでしょうか。

>> >> # auto_now_add = True　が「当たり」だとすると、これを使わない Datatime の
>> >> # Property を作成して自分で時刻を登録するようにすれば回避できそうですが...

>> >> 田中

>> >> 2008/12/15 19:28 dekopin271828182845904523536
>> >> <deko...@2.71828182845904523536.net>:

>> >> > はじめまして dekopin と申します
>> >> > 関係ないかも知れませんが
>> >> > インデックスが無い状態のときに
>> >> > GAEに appcfg.py upload する際に --force を付けても変わらないでしょうか？

>> >> > On 12月14日, 午後4:18, paptimus <papti...@gmail.com> wrote:
>> >> >> 北原さん

>> >> >> paptimusです。コメントありがとうございます。

>> >> >> > > created_onでソートしているのに、その順番でデータが取得出来ません。

>> >> >> 説明が下手で申し訳ありませんが、取得したデータセットのソートは、created_onの降順になっています。
>> >> >> （順番という言葉がよくなかったですね、失礼しました）
>> >> >> ただ、歯抜けになっていて、期待した件数が取得出来ていないという状況です。

>> >> >> 2008-12-14 14:26:35.000000 ○
>> >> >> 2008-12-13 14:26:35.000000 ×←例えば、このデータが抜けるということです
>> >> >> 2008-12-12 14:26:35.000000 ○
>> >> >> 2008-12-11 14:26:35.000000 ○

>> >> >> ちなみにローカルでは発生したことがなく、昨日気づくまでこのようなことになったことはありませんでした。
>> >> >> index.yamlにも、
>> >> >> - kind: Ownership
>> >> >>   properties:
>> >> >>   - name: deleted
>> >> >>   - name: user
>> >> >>   - name: created_on
>> >> >>     direction: desc
>> >> >> は作成されています。

>> >> >> また、頂いたアドバイスを元に、以下の確認をしてみました。
>> >> >> 1.上記のindex定義を削除
>> >> >> 2.--clear_datastoreオプションを付けてローカルサーバを起動
>> >> >> 3.この時点でデータストアが空になっており、index.yamlの全ての定義が
>> >> >> # Unused in query history -- copied from input.
>> >> >> となっていること、1で消したindex定義がないことを確認
>> >> >> 3.models.Ownership.all().filter('user', user).filter
>> >> >> ('deleted',False).order('-created_on')を呼ぶ
>> >> >> 4.1で消した定義と同じ内容が生成されており、冒頭が
>> >> >> # Used once in query history.
>> >> >> となっていることを確認
>> >> >> 5.サーバを落とし、1-2を再度実施し、
>> >> >> models.Ownership.all().filter('user =', user).filter
>> >> >> ('deleted',False).order('-created_on')
>> >> >> を呼ぶ
>> >> >> 6.4と同様になっていることを確認

>> >> >> ということで、ローカルでのindex生成はうまく言っていると考えています。

>> >> >> また、以下の手順も試してみました。
>> >> >> 1.上記のindexをindex.yamlから削除し、vacuum_indexを実行
>> >> >> 2.GAE上の当該indexがDeletingになっていることを確認
>> >> >> 3.当該indexの行が消えたら（deleteが完了したら）、
>> >> >> models.Ownership.all().filter('user =', user).filter
>> >> >> ('deleted',False).order('-created_on')
>> >> >> を呼び、NeedIndexErrorが以下で発生していることを確認。

>> >> >> no matching index found.
>> >> >> This query needs this index:
>> >> >> - kind: Ownership
>> >> >>   properties:
>> >> >>   - name: deleted
>> >> >>   - name: user
>> >> >>   - name: created_on
>> >> >>     direction: desc

>> >> >> 4.index.yamlに削除したindex定義を復活させ（NeedIndexErrorの内容と同じです）GAE上にアップロード、
>> >> >> 当該indexがBuildingになっていることを確認
>> >> >> 5.Servingになったことを確認し、
>> >> >> models.Ownership.all().filter('user =', user).filter
>> >> >> ('deleted',False).order('-created_on')
>> >> >> を呼び、エラーにならないことを確認。

>> >> >> その結果、やはり抜け落ちが発生していました。

>> >> >> 松尾さんのアドバイスから、一旦created_onからauto_now_add=Trueを外してアップロードし、抜け落ちるエンティティを別の一
>> >> >> 意に決まるキーで直接指定して検索した結果、エンティティは存在してヒットし、created_onも現在時刻ではなくputした日時が取得出来ま
>> >> >> す。

>> >> >> さらに、StringPropertyのカラムにindexを張りアップロードしたところ、やはり抜け落ちが発生します。

>> >> >> 抜け落ちたデータをローカルに投入して、同じ条件で検索したところヒットしました。

>> >> >> 以上から、GAEでのindex生成に謎がありそうです。

>> >> >> これまでの状況と、頂いたアドバイスからソースやデータの疑いを消していった結果をまとめると、以下のような感じです。
>> >> >> ・始めて抜け落ちに気づいた時までに、そのindexをvacuum、再構築をしたかは定かではない（adminログでは操作したindexの詳細まで
>> >> >> わからない＆覚えていないのでorz）
>> >> >> ・vacuum_index後に同じindexを再構築した場合、抜け落ちが発生している
>> >> >> ・vacuum、再構築を繰り返すと、抜け落ちがひどくなっていくみたい（検索にヒットする件数が減っていく...）
>> >> >> ・一旦抜け落ちたエンティティはvacuum、再構築後も出てこないように見える
>> >> >> ・そのエンティティは、別の条件で新たに作成したindexにも含まれていないみたい
>> >> >> ・抜け落ちたデータをindexを使わない条件（=だけ）で引っ掛けるとヒットする
>> >> >> ・そのデータをローカルで試しても問題ない

>> >> >> 昨晩、本家に拙い英語でpostしましたので、初回postのチェックが通ればそのうち反映されるかと思いますので、googleの方に直接見てもらえ
>> >> >> ればと思っています。

>> >> >> 長文失礼しました。

>> >> >> On 12月14日, 午後1:55, "Kitahara@Serow" <kitah...@serow.jp> wrote:

>> >> >> > paptimusさん

>> >> >> > index.yamlはクエリーの履歴から作成されるので、

>> >> >> > > created_onでソートしているのに、その順番でデータが取得出来ません。

>> >> >> > という現象が発生しているのであれば、index.yamlは作成されないと思います。

>> ...

>> もっと読む >>