+ Start a Discussion
krishnagkrishnag 

issue with governor limits while using Goggle Visualization API

hi,

 

I am using Google Visualization API for custom Report building on Visualforce pages.IN order to display the data in a graph where i am calculating the yearly data like number of accounts created in this year.

 

I used select count() from Accounts where Lead_Created_Date__c = This_Year; query which fetches the details the count of number of accounts created in this year.

 

I am hitting a governor limit since i have more than 10,000 accounts created this year. I heard that API has no governor limits then why I am getting this limit.I am using this query in controller of the visualforce page.I know the controller is an apex component so i Am getting this limitations.

 

Do u have any alternative suggestions to go ahead with it.

mtbclimbermtbclimber

If you make the same query via the Web Services API you will not hit this row-level limit. The Web Services API is limited by the aggregate number of requests made per day by the organization, not by the number of rows aggregated/scanned in a given request. I understand that this may seem counter-intuitive. We are looking at relaxing the row-level limits from within Apex to make the decision as to the entry point be not based on limits but rather your preference as a developer.

 

For integration with the Google Visualization API, you might check out the AJAX Toolkit which is a Javascript client to the Web Services API.

 

Hope this helps.

krishnagkrishnag

hi andrew,

 

thanks for your reply.But I am not clear what you trying to suggest.

mtbclimbermtbclimber

If you need to perform a count on more than 10k rows synchronously try calling the API via the Ajax toolkit (in javascript) for use with the visualization api from Google. Otherwise you need to add a limit to your query in Apex to keep you from hitting the limit and if your number is 10k indicate you've reached a "max" somehow in your interface.

 

If you are not concerned with synchronous calculations then an alternative would be to keep a stats table (custom object) that is maintained with scheduled and batch apex where in the case of the latter you can issue a query against more than 10k rows in order to generate aggregations as appropriate.  This will have the advantage of quicker performance when generating the data for the view upon request with the downside that it's only current up to the last calculation time interval.