geode-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Patrick Rhomberg <prhomb...@apache.org>
Subject Re: Better support for JSON gfsh results
Date Wed, 02 May 2018 22:49:43 GMT
I was under the impression that gfsh console output was intended as a more
"active" interface with an operator.  To that end, improved usability and a
more consistent output sounds like a boon to me.

On Tue, May 1, 2018 at 3:41 PM, Jens Deppe <jensdeppe@apache.org> wrote:

> Hi All,
>
> I'm working on removing our dependency on geode-json (org.json) in favor of
> Jackson. Initially this work has revolved around refactoring the internal
> results from gfsh commands (nothing that is user-visible).
>
> I'm now looking at the various gfsh 'data' commands (get, put, query and
> locate) and would very much like them to produce more meaningful, (actual
> JSON), structured results.
>
> For example, a get on a region containing a simple 'User' object produces
> this output.
>
> Result      : true
> Key Class   : java.lang.String
> Key         : jondoe
> Value Class :
> org.apache.geode.management.internal.cli.commands.
> GetCommandIntegrationTest.User
>
> This is not very helpful and only really shows that the value, for the
> given key, actually exists.
>
> Querying a PDX object is more informative:
>
> Result      : true
> Key Class   : java.lang.String
> Key         : jondoe
> Value Class : org.apache.geode.pdx.internal.PdxInstanceImpl
>
> username | hashcode
> -------- | --------
> jondoe   | 38de41a9
>
> This brings me to the actual question. Although our Java API is backwards
> compatible, the gfsh output has never been considered an 'API' in terms of
> the structure of it's output text. However, I do want to ask that if we
> start making changes to these commands, to produce actual JSON results,
> will that cause anyone any pain?
>
> Thoughts / comments?
>
> --Jens
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message