Hi Darren, I'm glad to hear that you find the Data Source Library useful.
As for your question, the straight forward answer is that it is not true that with SELECT you lose the library's aggregations etc. SELECT is designed for exactly this scenario, where you want to get a list of columns used but you don't need anything else. If you use SELECT, the completionQuery should contain all the aggregations, pivioting etc., and work fine assuming you put in your datatable all columns that appeared in the select clause of the dataSourceQuery. See AdvancedExampleServlet.java ( http://code.google.com/p/google-visualization-java/source/browse/trunk/examples/src/java/com/google/visualization/datasource/example/AdvancedExampleServlet.java) for an example of how to implement a data source that has only SELECT capability. However, if that doesn't work for you, you can bypass the entire capabilities mechanism, and still use whatever computational abilities the library gives you (aggregations, pivoting, filters, ...) by customizing the flow yourself. See example/AdvancedExampleServlet2.java ( http://code.google.com/p/google-visualization-java/source/browse/trunk/examples/src/java/com/google/visualization/datasource/example/AdvancedExampleServlet2.java ). That example uses splitQuery with the SELECT capability, but you can also use it in whatever way you see fit. Calling applyQuery() will perform the query for you whichever way you want it. I suggest you use former solution rather than the latter because it is tailored exactly for your case, but if you're having problems with it, you can always go for the latter. Regards, VizWiz On Fri, Jun 12, 2009 at 4:34 AM, Darren <[email protected]> wrote: > > First off, let me say that the Java Data Source Library is awesome. I > had actually implemented the non-optional parts of the data source > spec and was starting on parsing for the query language when I heard > about the library at Google I/O. The API was easy and straightforward > enough that I managed to swap out most of our implementation for > Google's while sitting in the audience at I/O. > > The only place the library fell short for me was in specifying the > Capabilities of my DataTableGenerator. I'm building on top of a very > basic data store with hundreds of numeric columns, so I'd really like > the library to handle all of the aggregation, grouping, pivoting, etc. > for me. However, I'd still like to see the incoming query so I can > load the correct columns from the back end data store. Unfortunately, > the library splits the query into parts it handles (which is > everything, with Capabilities.NONE) and the part the > DataTableGenerator handles (which is nothing). If I instead specify > Capabilities.SELECT, I receive the SELECT part of the query, but I can > no longer use the library to handle the aggregation functions (sum, > avg, etc). > > I can work around this by parsing the entire query from the request > and manually getting the columns from it; however, this seems like a > less-than-ideal situation, especially since we end up performing both > the parsing and the row-filtering twice. Ideally, there would be a > more fine-grained Capability where I would receive a simple list of > the columns that the library wants, and the library would handle the > rest. > > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Google Visualization API" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/google-visualization-api?hl=en -~----------~----~----~----~------~----~------~--~---
