Re: other data types - yes, those can and probably should be added. Just didn't have a need for them when I wrote it.
Re: result set metadata - I don't think we need it. The ResultList.Field class specifies the desired value type. If the type is null, the default type returned by the result set is used. Re: more compact formatting - that is up to the serializer you use. If you want a more compact format, you can use CSVSerializer instead of JSONSerializer. On Jan 28, 2010, at 7:11 PM, Sandro Martini wrote: > Hi to all, > I've started to look at the new (interesting) class ResultList ( > https://issues.apache.org/jira/browse/PIVOT-93 ), and I have some > questions (mainly for curiosity) on it: > - resultset metadata is never used (nor when the given type is null, > but this could be a good case), why ? > - some common and standard SQL types are not handled, like CHAR, DATE, > TIMESTAMP for example > (sorry, I haven't time to test adding fields to the test DB table > and trying ... I hope to do it soon) > there is some reason (maybe they work the same, or simply wasn't > needed in a real use case, or problems serializing them in json, or > other ...) ? > - on *LOB someone has tried ? less important, ok, just for curiosity ... > > Let me know if I can help. > > > And last, a flight on this: > what do you think on a method that instead of a List (where any record > is written as fieldName: fieldValue), of a more compact form like a > map where for example we can have an header row containing field names > and related data (opt., like type, description, length, nullable, etc) > and then any row containing only the values, field by field ? For many > data could be a space saver in the generated json. > Could be an addiction to the existing behavior, if wanted ... and > don't worry, just an idea. > > > Thanks a lot, > Sandro
