Fixed
Status Update
No update yet.
Comments
be...@google.com
Would you be able to describe your use case of why you need to do on the order of hundreds of directions requests please?
se...@google.com
Sure. This is my application: http://lstsim.de/
It is in German, so here's a short description: It's a simulation of an emergency services dispatch center. The user is in charge of sending ambulances to different places all over the area. I'm using the Directions Service, so the ambulances on the map use the actual roads (and even respect the speed limits). Every trip from one location to another takes a single request. This allows me to achieve a pretty realistic replication of the reality.
This also means I don't actually need a routing request every second, but it rather depends on how busy things are in the game. My users were reporting routing errors usually after 300 routings and about an hour or so of playing, so you get an idea of the average request rate.
It is in German, so here's a short description: It's a simulation of an emergency services dispatch center. The user is in charge of sending ambulances to different places all over the area. I'm using the Directions Service, so the ambulances on the map use the actual roads (and even respect the speed limits). Every trip from one location to another takes a single request. This allows me to achieve a pretty realistic replication of the reality.
This also means I don't actually need a routing request every second, but it rather depends on how busy things are in the game. My users were reporting routing errors usually after 300 routings and about an hour or so of playing, so you get an idea of the average request rate.
be...@google.com
This problem sounds similar to behavior I am seeing with versions 3.10+ ... my application allows users to create maps of their addresses. After 200 or so rows the geocoder becomes very very slow, even if I delay geocodes 5-10 seconds in-between.
Since the limit is 2500 per day, does it not seem reasonable that you would be able to send a geocode 1 per second as you have in the past until you reach 2500? If this is a change to the quota and limits of the free google maps API please let us know.
Since the limit is 2500 per day, does it not seem reasonable that you would be able to send a geocode 1 per second as you have in the past until you reach 2500? If this is a change to the quota and limits of the free google maps API please let us know.
mm...@commonsware.com
Google is forcing 3.10 now so there is no using 3.9 to get around this bug.
I need to know if this is a permanent change on geocoding quotas or if this is truly a bug. If it is a permanent change I will need to make big changes to our app so users can only create maps of 200 or less points, whereas before it was possible to create 2500 marker maps.
I need to know if this is a permanent change on geocoding quotas or if this is truly a bug. If it is a permanent change I will need to make big changes to our app so users can only create maps of 200 or less points, whereas before it was possible to create 2500 marker maps.
ya...@google.com
Any update on this? Is it a bug or a change?
yb...@google.com
because it holds a transaction in the database, it will isolate the queries.
Cursor does this weird thing where it re-runs the query to fill the next window. Since it is another query, unless there is a transaction, it may load totally different data.
i don't like the idea of turning it on for every single query because it will simply make the db access single threaded for a super super edge case (especially after we have paging).
maybe we can make it a builder parameter (off by default) and also support @Transaction in selection methods?
Cursor does this weird thing where it re-runs the query to fill the next window. Since it is another query, unless there is a transaction, it may load totally different data.
i don't like the idea of turning it on for every single query because it will simply make the db access single threaded for a super super edge case (especially after we have paging).
maybe we can make it a builder parameter (off by default) and also support @Transaction in selection methods?
se...@google.com
An update on this would be greatly appreciated by our users. Thank you.
yb...@google.com
Any updates on this issue? When will this bug be fixed.
yb...@google.com
Any updates about this defect?
yb...@google.com
i think for now we should just ensure that Relationship queries are fetched in a transaction so that they are consistent.
If we can implement this in a cursor wrapper, that would be the best.
Besides, this is something that needs to be handled in the FrameworkSQLiteDatabase since it is the only one that can figure out the windowing.
As long as the Cursor is not passed to the outside world, it seems reasonable to create a cursor wrapper that holds a transaction until it is closed.
If we can implement this in a cursor wrapper, that would be the best.
Besides, this is something that needs to be handled in the FrameworkSQLiteDatabase since it is the only one that can figure out the windowing.
As long as the Cursor is not passed to the outside world, it seems reasonable to create a cursor wrapper that holds a transaction until it is closed.
yb...@google.com
So, it's about one year after my last question about the actual status of this defect. Are there any updates?
yb...@google.com
So, it's about one year after my last question about the actual status of this defect. Are there any updates?
Description
we should probably wrap all reads into a transaction. This will slow down parallel reads (because android grabs locks in java level) but maybe it is worth the improvement. Alternatively, we can support @Transaction annotation in queries and let the developer decide.