Closed GoogleCodeExporter closed 8 years ago
Is that relevant to this as well:
Do an advanced search on Japanese pages for 青 like this:
http://www.google.com/search?hl=en&as_q=%E9%9D%92&as_epq=&as_oq=&as_eq=&num=10&l
r=lang_ja&as_filetype=&ft=i&as_sitesearch=&as_qdr=all&as_rights=&as_occt=any&cr=
&as_nlo=&as_nhi=&safe=off
Next through the API (normally with key):
http://ajax.googleapis.com/ajax/services/search/web?v=1.0&lr=lang_ja&q=%E9%9D%92
Normal search shows: Results 1 - 10 of about 838,000 Japanese pages for 青
API search shows: "236000" for the cursor.estimatedResultCount
A 600000 results difference is a bit odd.
Original comment by asheme...@gmail.com
on 1 Jun 2008 at 8:36
Original comment by internal...@gmail.com
on 3 Jun 2008 at 5:51
This problem has been unresolved for 3 months, is anyone actually working on
this ?!
Original comment by brami...@gmail.com
on 28 Jul 2008 at 8:27
Would like to see this resolved too. I'm using the API from PHP via JSON and
this is
a bit embarrasing because because the client thinks it's my error.
Original comment by johnpitc...@gmail.com
on 30 Jul 2008 at 3:10
This and Defect 32 seem to be the same thing. For my issues see Defect 32.
Original comment by a_star_c...@hotmail.com
on 27 Aug 2008 at 5:48
Issue 158 has been merged into this issue.
Original comment by jrgeer...@gmail.com
on 27 Nov 2008 at 2:13
This problem has been unresolved for 10 months, is anyone actually working on
this ?!
Original comment by fensterm...@gmail.com
on 5 Mar 2009 at 9:09
This happens because the number of pages relies on the estimated result count,
which is inherently inaccurate
because it is only an estimate. This is by design and there are currently no
plans to change it.
Apologies for any inconvenience.
Original comment by lisba...@google.com
on 5 Mar 2009 at 9:15
This is so ridiculous! I can't believe Google has no plan to fix this issue. If
that
is your design model for this application it should seriously be reconsidered.
Why
not verify that each result page in the pagination result set will contain data
before setting the value of cursor.pages.length? Is there a work around for this
issue or anything? It makes sites that use this technology look poorly designed.
Original comment by andek...@gmail.com
on 30 Apr 2009 at 7:47
I'm not entirely sure, but the problem I am running into may be related to this:
http://groups.google.com/group/Google-AJAX-Search-API/browse_thread/thread/93691
75170287418#
It practically renders any information carried by the result cursor useless.
For me,
it just happens on the first page though: Say the cursor reports 100 results,
and 4
pages of result data with 8 results each, then the first page may sometimes
contain
only 2 results, while the following pages are fully populated with 8 results...
This breaks any pagination in the UI and one must resort to hacks to fix this
(e.g.
dispatching the first query twice should the result data be incomplete).
This is indeed a major issue, please fix this ASAP!
Original comment by m.kaepp...@gmail.com
on 4 May 2009 at 12:00
Working on more accurate estimates would really be helpful. It's very
disconcerting
when pages don't exist!
Original comment by searchto...@gmail.com
on 19 Jun 2009 at 9:28
I have to agree with "fenstermakera" this issue is so big it kinda makes the
websearch API useless. I mean no one wants their website to look as
unprofessional as
to claim that there are 4 pages of results when there are actually only 2. I've
been
hacking at this thing for days and can't come up with a work around, which has
lead
me to genuinely consider switching to yahoo's API, which bums me out, because
google
rocks. I've always said I look forward to the day when I find something about
google
I don't like... but I take it back, I want this API to work. :-(
Original comment by Lamba...@gmail.com
on 22 Jun 2009 at 10:05
I also agree this needs to be fixed. I thought there was a problem with my code
or
something I did wrong. Then I noticed when I copied the basic code from the CSE
Code
section, it provided 8 pages in the bottom, however not all results had 8
actual page
results. So you would click on page 8 but it would instead put you on Page 4 and
there were no further numbered pages....
This is an issue that needs to get resolved please. Since the javascript API
limits
the result set to 64... why not then do a count of the results up to 64? If it
exceeds 64 then stop the count, if it's lower (which is the issue for us) then
set
the proper and accurate number of the counter. Having proper pagination is
important.
Original comment by leggetts...@gmail.com
on 24 Jul 2009 at 4:06
same problem with french version of the API. Can it be resolved ? that's really
annoying for users.
Original comment by jerome.g...@gmail.com
on 30 Nov 2009 at 11:49
how you managed to parse and present google search api result pages in php ?
...in
order to display 1, 2, ...>next pages ?
thx
Original comment by shmeker...@gmail.com
on 21 May 2010 at 11:29
Also having this issue would love it to get fixed...
Original comment by loweg...@gmail.com
on 15 Jul 2010 at 3:01
Hi folks. I may have a simple workaround for some of you. NOTE: This
workaround is highly implementation specific.
In my implementation I effectively have one <div> per result returned. All of
my results are contained within one parent <div>. So if I set
gLocalSearch.setResultSetSize(8) then I will normally have 8 result children
<div>'s within my one parent <div> per each page my user's cycle through. It
should look something like this. For simplicity I am making this pretty bare
bones.
<div id="parent">
<div class="resultChild"/>
<div class="resultChild"/>
<div class="resultChild"/>
<div class="resultChild"/>
<div class="resultChild"/>
<div class="resultChild"/>
<div class="resultChild"/>
<div class="resultChild"/>
</div>
Now, in the case that the pages.length is off as explained above (and in my own
issue as well) I end up less than 8 result children. In my example I am only
on page 2 of 4 so I expect I have 2 more pages coming, but lo and behold I only
have 2 result children.
<div id="parent">
<div class="resultChild"/>
<div class="resultChild"/>
</div>
So I added in a check that also counts the number of result children and
compares that to the value used in gLocalSearch.setResultSetSize() which in my
case is 8.
Here is an example of how I did this using jQuery.
var resultReturned = jQuery("#parent > .resultChild").size();
Then
var resultSize = gLocalSearch.getResultSetSize();
Finally
if resultReturned < resultSize then I know I have a case where I will override
what pages.length is telling me.
This is not what I would call optimal, but given the circumstances this was a
simple solution that works well for me. Hopefully it might help out one of you.
Take care :)
Original comment by Sonic...@gmail.com
on 16 Sep 2010 at 5:20
One fix that's seems to be working for me, it to make additional requests.
The problems allways seems to be that early pages show that there are to many
additional pages - the later pages show the "correct" number, or at least the
smallest number of pages.
First you make the request with start=0.
Then find out how many pages there are, make a request with start set to that
number of pages and check how many pages there area now.
Save the new totalpages gotten with that latest request, and make now write
your pagination.
This is by no means a perfect solution, and it requires an additionl request,
but atleast it sidesteps the problem with pagination changing with every page.
Original comment by s...@bluerange.se
on 18 Oct 2010 at 7:50
The number of items in cursor pages is based on the Estimated Results Count.
As described in issue #32, this estimate is not always correct. For most
queries, it's not a problem. However, for queries with only a couple pages,
the cursor might be unreliable. Unfortunately, this is a facet of how the
pages[] are calculated and cannot be fixed.
Original comment by adam.fel...@gtempaccount.com
on 10 Nov 2010 at 10:43
Original comment by adam.fel...@gtempaccount.com
on 13 Nov 2010 at 2:21
Original issue reported on code.google.com by
lisba...@gmail.com
on 1 May 2008 at 6:10