Fixed
Status Update
Comments
ac...@gmail.com <ac...@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
yb...@google.com <yb...@google.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]
ac...@gmail.com <ac...@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...
ac...@gmail.com <ac...@gmail.com> #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.
tm...@gmail.com <tm...@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.
tm...@gmail.com <tm...@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.
yb...@google.com <yb...@google.com> #8
This one really needs to be addressed...
tm...@gmail.com <tm...@gmail.com> #9
Fixed in 1.1.6
yb...@google.com <yb...@google.com> #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!
yb...@google.com <yb...@google.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!
yb...@google.com <yb...@google.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.
yb...@google.com <yb...@google.com> #13
there is a new xerial version available that includes the fix CL.
next version of room will depend on it.
next version of room will depend on it.
wo...@gmail.com <wo...@gmail.com> #14
Great! Any idea when? I have to force-kill the process every few builds right now unless I want to wait for 20 minutes till it OOM's.
yb...@google.com <yb...@google.com> #15
probably next week.
you can try to add `org.xerial:sqlite-jdbc:3.20.1` to your annotationProcessor configuration to override the version, it will help some but we also needed to change Room to properly take advantage of the new version so proper fix will be only when we ship.
you can try to add `org.xerial:sqlite-jdbc:3.20.1` to your annotationProcessor configuration to override the version, it will help some but we also needed to change Room to properly take advantage of the new version so proper fix will be only when we ship.
yb...@google.com <yb...@google.com> #16
change is merged, will be fixed in next release.
al...@gmail.com <al...@gmail.com> #17
I tested the bug fix and the issue is still around but happens fewer times.
[Deleted User] <[Deleted User]> #18
#17: As #3 said above, DataBinding also have OOM problem. Did you use DataBinding?
al...@gmail.com <al...@gmail.com> #19
Yes, but I'm using the latest version (gradle 3.0.0) and I still have this issue.
Description
Version used: alpha2
Devices/Android versions reproduced on: all
Since I am using the libs, my Android Studio (v2.3.2) is entering a loop while building my project which results into a heap full exception. I would like to give you more details about that problem, but I'm not sure how to provide those.