Hi, Fred, Thanks for your interest in FastBit software. If you are planning to extend FastBit in someway, it would be much better to do it in C++. The Java API is based on a very old C API that requires data to be on disk already.
John On 9/10/14 7:33 AM, Fred Oko wrote: > Aim is to be able to access aggregates via JNI w/ greater efficiency > of not having to pull back all the hit values via get_qualified_ints etc. > > I started by just attempting to add support for > fastbit_build_result_set and passing a select clause with aggregates. > But : > 1) this returns the aggregate for teh wrong column (e.g. if asking for > sum(colB) it would return a sum for a different column as was visible > by returned aggregate and the debug logging showing access to said > other column (apparently lexicographically selected) > 2) as one starts tracing where that went wrong, one realizes this > method will return a record with those aggreagtes for each hit as that > is what the result set would contain -- given that it seem inefficient > and based on query.h comment "If any additional functions are needed > in the select clause, use the function ibis::table::select instead of > using this class" I turned to that > > From there I took the thula example as a better starting point over > tcapi and did manage do get the functionality of thula doQuery into > the capi and access it via JNI. However I want to make certain what > would be the best way to proceed now that I have validated this was > feasible. > 1) do you agree ibis::table.select is optimal for the case of wanting > a couple of aggregates over a couple of columns (not necessarily teh > same as in the where clause) for a set of where clauses against a table? > 2) do you have recommendation on how to best expose this -- adding the > table facade to FastBitQuery seems cleanest but for now I'm just > exposing a specialized function > 3) do you any arguments against a count(*) to the select clause to > have one complete select response instead of having to mix in a > separate request for num hits? -- it appears if using table.select I > won't need to use the query interface and the table mechanisms are > separate for computing hits > 4) any concerns with this approach on memory cleanup or optimizations > given that these queries will be run within a long lived container? > > Thx in advance > > > _______________________________________________ > FastBit-users mailing list > [email protected] > https://hpcrdm.lbl.gov/cgi-bin/mailman/listinfo/fastbit-users > _______________________________________________ FastBit-users mailing list [email protected] https://hpcrdm.lbl.gov/cgi-bin/mailman/listinfo/fastbit-users
