Some parts of schemas need a spec that is standardized cross language (in
particular, the definition of what a schema is). Other things can be
language specific. The next step with schemas will need to be formalizing
those answer.
On Mon, Jan 7, 2019 at 2:13 PM Robert Burke wrote:
> In the
In the eventual future where the Go SDK supports schemas, it should be
possible to use struct Field Tags to specify paths for extraction from
schema data, for usage similar to what Java uses parameter Annotations.
eg.
type MyKey struct {
K string `jsonpath:userid`
}
type MyValue struct{
K
I'll take a look.
Honestly though, if we leave out features such as array slices this is a
dirt-simple path syntax, that pretty much matches what SQL does. It's
basically just field1.field2, or field1.*.
JMESPath along with JsonPath also supports various aggregations, which I
think is beyond
There is also JMESPath (http://jmespath.org/) which is quite similar to
JsonPath, but does have a spec and lacks the leading $ character. The AWS
CLI uses JMESPath for defining queries.
On Mon, Jan 7, 2019 at 1:05 PM Reuven Lax wrote:
>
>
> On Mon, Jan 7, 2019 at 1:44 AM Robert Bradshaw
>
On Mon, Jan 7, 2019 at 1:44 AM Robert Bradshaw wrote:
> On Sun, Jan 6, 2019 at 12:46 PM Reuven Lax wrote:
> >
> > Some time ago, @Jean-Baptiste Onofré made the excellent suggestion that
> we look into using JsonPath as a selector format for schema fields. This
> provides a simple and natural
On Sun, Jan 6, 2019 at 12:46 PM Reuven Lax wrote:
>
> Some time ago, @Jean-Baptiste Onofré made the excellent suggestion that we
> look into using JsonPath as a selector format for schema fields. This
> provides a simple and natural way for users to select nested schema fields,
> as well as
Some time ago, @Jean-Baptiste Onofré made the excellent
suggestion that we look into using JsonPath as a selector format for schema
fields. This provides a simple and natural way for users to select nested
schema fields, as well as wildcards. This would allow users to more simply
select nested
