Obsolete
Status Update
Comments
el...@gmail.com <el...@gmail.com> #2
Important addition!!!!!
The App just stopped working again and is giving me the NeedIndexError again! This
coincided with my re-addition of the superset (ancestor only) index going from status
"building" to "serving".
So, I think it might be clear what is going on:
With an index setup like this:
indexes:
- kind: Segment
ancestor: yes
- kind: Segment
ancestor: yes
properties:
- name: rev
The second index seems to be hidden by the first one, since it is a subset of the
first. Deleting the first index exposes the second one.
After deleting the first index out of index.yaml and running "appcfg.py update", a
call to "appcfg.py vacuum_indexes" outputs this:
Fetching index definitions diff.
This index is no longer defined in your index.yaml file.
ancestor: true
kind: Segment
properties: []
Are you sure you want to delete this index? (N/y/a): y
Deleting selected index definitions.
Error 500: --- begin server output ---
Server Error (500)
A server error has occured.
--- end server output ---
After this, the app works again, despite the error.
This problem only seems to be happening if an ancestor is involved.
I hope this helps.
Thanks,
Markus
The App just stopped working again and is giving me the NeedIndexError again! This
coincided with my re-addition of the superset (ancestor only) index going from status
"building" to "serving".
So, I think it might be clear what is going on:
With an index setup like this:
indexes:
- kind: Segment
ancestor: yes
- kind: Segment
ancestor: yes
properties:
- name: rev
The second index seems to be hidden by the first one, since it is a subset of the
first. Deleting the first index exposes the second one.
After deleting the first index out of index.yaml and running "appcfg.py update", a
call to "appcfg.py vacuum_indexes" outputs this:
Fetching index definitions diff.
This index is no longer defined in your index.yaml file.
ancestor: true
kind: Segment
properties: []
Are you sure you want to delete this index? (N/y/a): y
Deleting selected index definitions.
Error 500: --- begin server output ---
Server Error (500)
A server error has occured.
--- end server output ---
After this, the app works again, despite the error.
This problem only seems to be happening if an ancestor is involved.
I hope this helps.
Thanks,
Markus
mo...@gmail.com <mo...@gmail.com> #3
I've repro'd Markus's problem in a simpler context, which may help with tracking it
down. (BTW Markus,bigsheetofpaper.com is *great* :) )
After completing the App Engine tutorial, I ran appcfg update. Attempting to view
the root URL [which requests Greeting.all().order('-date').fetch(10)] gave a
NeedIndexError for the following index spec:
- kind: Greeting
properties:
- name: date
direction: desc
This was the content of my index.yaml file, minus comments:
- kind: Greeting
properties:
- name: author
- name: date
direction: desc
- kind: Greeting
properties:
- name: date
direction: desc
Both indexes showed as "serving" on my App dashboard's Index page.
Taking a hint from Markus, I deleted the first entry in my index.yaml file, which was
an unused remnant from earlier code. After another appcfg update, I no longer
received the error, and only one index is in my dashboard's list.
Interestingly, I then put back the deleted entry and re-updated, and the error does
not reappear. Both indexes are listed again on the dashboard.
Hope this helps,
Michael [gundlach at you-can-guess-where]
down. (BTW Markus,
After completing the App Engine tutorial, I ran appcfg update. Attempting to view
the root URL [which requests Greeting.all().order('-date').fetch(10)] gave a
NeedIndexError for the following index spec:
- kind: Greeting
properties:
- name: date
direction: desc
This was the content of my index.yaml file, minus comments:
- kind: Greeting
properties:
- name: author
- name: date
direction: desc
- kind: Greeting
properties:
- name: date
direction: desc
Both indexes showed as "serving" on my App dashboard's Index page.
Taking a hint from Markus, I deleted the first entry in my index.yaml file, which was
an unused remnant from earlier code. After another appcfg update, I no longer
received the error, and only one index is in my dashboard's list.
Interestingly, I then put back the deleted entry and re-updated, and the error does
not reappear. Both indexes are listed again on the dashboard.
Hope this helps,
Michael [gundlach at you-can-guess-where]
dr...@gmail.com <dr...@gmail.com> #4
Just wait...
when the Data Store Indexes' status is "Serving", I think everything will be ok.
Hope this is the reason.
Actually, I don't know how it works...
when the Data Store Indexes' status is "Serving", I think everything will be ok.
Hope this is the reason.
Actually, I don't know how it works...
pa...@voltar.org <pa...@voltar.org> #5
I have the same problem. In my app I have two indices, one is a superset of another (has an
additional property):
# index A
- kind: UserRelease
ancestor: yes
properties:
- name: artist_id
- name: order
direction: desc
# index B
- kind: UserRelease
ancestor: yes
properties:
- name: order
direction: desc
The query involving index A raises a NeedIndexError exception even though the index is available and
its status is "Serving".
If I vacuum index B, index A starts to work. When I put back index B, index A doesn't work again.
The error occurs only in the production environment, everything works fine locally. It looks like
index B somehow "hides" index A. This is clearly a bug, please fix it.
additional property):
# index A
- kind: UserRelease
ancestor: yes
properties:
- name: artist_id
- name: order
direction: desc
# index B
- kind: UserRelease
ancestor: yes
properties:
- name: order
direction: desc
The query involving index A raises a NeedIndexError exception even though the index is available and
its status is "Serving".
If I vacuum index B, index A starts to work. When I put back index B, index A doesn't work again.
The error occurs only in the production environment, everything works fine locally. It looks like
index B somehow "hides" index A. This is clearly a bug, please fix it.
mi...@gmail.com <mi...@gmail.com> #6
Forgot to mention. I didn't get this error until I started using ancestor indices.
That is, if in the indices above I replace "ancestor: yes" with an additional
property (e.g. "- name: user_id") and update the entities and queries accordingly,
then both indices work fine.
That is, if in the indices above I replace "ancestor: yes" with an additional
property (e.g. "- name: user_id") and update the entities and queries accordingly,
then both indices work fine.
re...@gmail.com <re...@gmail.com> #7
I am also having this issue, also using ancestor. For me, it doesn't seem to matter
which order the indexes are in index.yaml -- whichever index definition comes first
"blocks" the other index definition, so only one can be used.
This is especially frustrating because I just refactored a bunch of code to make use
of the ancestor relationship. Meh.
which order the indexes are in index.yaml -- whichever index definition comes first
"blocks" the other index definition, so only one can be used.
This is especially frustrating because I just refactored a bunch of code to make use
of the ancestor relationship. Meh.
br...@gmail.com <br...@gmail.com> #8
This one really needs to be addressed...
en...@google.com <en...@google.com>
br...@gmail.com <br...@gmail.com> #9
Fixed in 1.1.6
pa...@voltar.org <pa...@voltar.org> #10
i have an error like this
HTTP ERROR 404
problem accessing/greeting2.reason
NOT FOUND
tell ideas to solve this!
HTTP ERROR 404
problem accessing/greeting2.reason
NOT FOUND
tell ideas to solve this!
dr...@gmail.com <dr...@gmail.com> #11
i have an error like this
HTTP ERROR 404
problem accessing/greeting2.reason
NOT FOUND
tell ideas to solve this!
HTTP ERROR 404
problem accessing/greeting2.reason
NOT FOUND
tell ideas to solve this!
al...@gmail.com <al...@gmail.com> #12
I got the same error, what I missed what that I deleted all the content from index.yaml for some reason. Including this:
<code>
indexes:
# AUTOGENERATED
# This index.yaml is automatically updated whenever the dev_appserver
# detects that a new type of query is run. If you want to manage the
# index.yaml file manually, remove the above marker line (the line
# saying "# AUTOGENERATED"). If you want to manage some indexes
# manually, move them above the marker line. The index.yaml file is
# automatically uploaded to the admin console when you next deploy
# your application using appcfg.py.
</code>
After I included this content, deleted indexes using "appcfg.py vacuum_indexes", and updated my app (wainting for the new indexes to build) it all worked.
<code>
indexes:
# AUTOGENERATED
# This index.yaml is automatically updated whenever the dev_appserver
# detects that a new type of query is run. If you want to manage the
# index.yaml file manually, remove the above marker line (the line
# saying "# AUTOGENERATED"). If you want to manage some indexes
# manually, move them above the marker line. The index.yaml file is
# automatically uploaded to the admin console when you next deploy
# your application using appcfg.py.
</code>
After I included this content, deleted indexes using "appcfg.py vacuum_indexes", and updated my app (wainting for the new indexes to build) it all worked.
mi...@protonmail.ch <mi...@protonmail.ch> #13
I guess this continues in issue 36947130
Description
When I have installed them on my 4.0.4 GSM Galaxy Nexus, I Have been forced to set up a pattern/pin/password unlock and thus I can no more use slide to unlock or face unlock.
I don't want that. I can easily ban those certificates at the server side, so the client security that android enforces seems to me useless.
I understand that it can be usefull in some circunstances, but the user should still have the choice.
Android could strongly advice the user to set up a secure unlock, but should always let him decide.
Android is all about giving control to the user. I think this default security policy is the opposite ...
Of course, when the certificate is distributed in a configuration profile which enforce a certain client security level (such as exchange), the policy should still apply.
What I would like is a configuration screen or a settings file somewhere where we could define/alter the default security policy.
Thank you for your attention