ResultList, some questions

[Sandro Martini <sa...@gmail.com>]

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

Re: ResultList, some questions

[Sandro Martini <sa...@gmail.com>]

Hi Greg,
just reopened and assigned to me, but be free to change it ...

Bye,
Sandro

Re: ResultList, some questions

[Greg Brown <gk...@mac.com>]

>> Re: other data types - yes, those can and probably should be added. Just didn't have a need for them when I wrote it.
> Ok, so do you think it would be a good thing to reopen the ticket, or
> better to open another one as improvement or new feature ?

You can reopen it if you like.

>> 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.
> Uh, i never use the CSVSerializer and probably this is the most useful
> in this case ...
> But I'm interested also to see what happen after adding the other data types ...

CSVSerializer simply converts all values to strings by calling toString().

Re: ResultList, some questions

[Sandro Martini <sa...@gmail.com>]

Hi Greg
> Re: other data types - yes, those can and probably should be added. Just didn't have a need for them when I wrote it.
Ok, so do you think it would be a good thing to reopen the ticket, or
better to open another one as improvement or new feature ?

> 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.
Yes, I was thinking if metadata gave us more freedom, but probably you
have reason, it's not needed.

> 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.
Uh, i never use the CSVSerializer and probably this is the most useful
in this case ...
But I'm interested also to see what happen after adding the other data types ...

Tell me if I can help on this.

Bye

Re: ResultList, some questions

[Greg Brown <gk...@mac.com>]

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