Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
    codesupremojr
    @codesupremojr
    I tried this filter, data[?contains(@, 'ORD001') == true]."ifname"
    but not working for me
    anything I missed? Thanks a lot
    Maxime Labelle
    @springcomp

    The source data is weird as the data property is an array of JSON objects, each of which has a different schema.
    So your expression makes it look like you want to find all JSON objects in data where there exists a property whose value is ORD001 – thereby returning the single object { "description": "ORD001 | Singapore" } from the collection.
    From there, you seem to want to return the value of the ifname property for that object. As the single matching object does not have an ifname property, the whole expression would return null.

    Can you clarify your exact requirements ?

    JosephJohnKarl
    @JJKW1984
    Hello
    Nolan Woods
    @innovate-invent
    I think @codesupremojr highlights the issue with having variadic functions like merge(). This could easily be done with merge(data).(contains(description, 'ORD001') && ifname || null) but merge is variadic and cant accept a list of objects. I also don't think that a spread operator is what is needed, we just need to replace all variadic functions.
    This is also not syntactically possible given that subexpression doesn't allow parenthesis
    Nolan Woods
    @innovate-invent
    (assuming 'data' is within some sort of projection)
    snowplayfire
    @snowplayfire
    how can i get value from a map with certain key?
    Nolan Woods
    @innovate-invent
    can you provide an example?
    hell-racer
    @hell-racer
    No example provided, timeout expired, issue automatically closed. (c)
    Maxime Labelle
    @springcomp
    🤣
    By any chance, @hell-racer , have you had a try to our proposal for arithmetic-expressions ?
    hell-racer
    @hell-racer
    I didn't even know there is a sandbox for preview features ))
    hell-racer
    @hell-racer
    Still looks like the necessity to create an object to be able to use arithmetic operations with values from different levels of source data makes them hard to use... I get that the other options are hard to implement, and expressions themselves may be hard to reason about, but...
    Maxime Labelle
    @springcomp
    No, no, your original expression works. You can try it out : a.b + c.d. Nice and easy !
    It’s the same as a.b || c.d really.
    image.png
    hell-racer
    @hell-racer
    OMG!
    How did you do that?
    Maxime Labelle
    @springcomp
    I did nothing. It just works™.
    I was .not thinking straight when I argued the JEP
    hell-racer
    @hell-racer
    That's fantastic )
    So, according to Preview Features root-access syntax ($.abc) isn't making it into the spec?
    Maxime Labelle
    @springcomp

    @hell-racer , you know @innovate-invent and I are just two guys on the Internet.
    You can have a voice.
    And the more community members are involved, the better.

    We are having quite some heated debates with regards to $.
    Currently, it is being specified as a JEP, as you may have seen, but due to some debate, I feel it cannot be included in the very next immediate short term milestone.

    But I would love to have those discussions.

    My position is that $ as the root node is quite handy and is worthy of inclusion.
    I think @innovate-invent wants $ to have a more ambitious destiny.
    This is central to the reduce feature.
    Currently, we both think that JMESPath needs a reduce feature.
    image.png
    My position is that, since we have map() we should have reduce().
    To perform some sums, products, aggregates, etc.
    Nolan Woods
    @innovate-invent
    My position is that map() was a mistake
    Maxime Labelle
    @springcomp
    image.png
    @innovate-invent would rather have that implemented as syntax:
    That’s where $ could play a role, by representing the currently being accumulated value in the reduce operation.
    Nolan Woods
    @innovate-invent
    I would rather see we don't compound that mistake
    hell-racer
    @hell-racer
    My thought is that $ as a root access will be intuitive since JsonPath has it, and a lot of people come from JsonPath to JmesPath when they stumble upon some unsolvable problem.
    Maxime Labelle
    @springcomp
    @hell-racer the preview feature page is incomplete.
    Preview actually include all the string manipulation functions, a new map_by() function that we feel uses the correct order for its arguments.
    And many more.
    Nolan Woods
    @innovate-invent
    @hell-racer, how would you feel about making backwards incompatible changes?
    you seem to spend a lot of time working with JMESPath
    Maxime Labelle
    @springcomp
    @hell-racer feel free to review the discussions around $ in the spec repository.
    hell-racer
    @hell-racer
    Yeah... since I've implemented an integration service using a templating engine based on JmesPath, all the integrations are done by using these templates :). We write C# code when we need another custom function or to call some new service for additional source data, everything else is done via templates :).
    I feel ok when breaking changes are under some feature toggles, but I imagine it's hard to do when we're talking about spec and not about concrete implementation.
    It is also possible to version entire spec... I remember Python had some breaking changes from 2 to 3. But when it's necessary to support more than one spec it's not very convenient.
    Maxime Labelle
    @springcomp
    @hell-racer among the would-be JEPs that we did not include in the next milestone (yet), are there some you feel need to be included right away?
    hell-racer
    @hell-racer
    For some reason, I didn't encounter a single task where I would need reduce, so in my case $ would be better just as the root node. But I understand there are certainly some cases where reduce will be handy.
    Maxime Labelle
    @springcomp
    That’s really interesting. Have you seen other uses cases, maybe amongst those that are just rough ideas and that we would then need to elaborate with higher priority?
    And thank you for your feedback. This is very valuable.
    hell-racer
    @hell-racer

    There is some caveat when using functions... Imagine you're accessing a node, and there is no such node. So it just returns null. But when you use a function, such as length(), if its argument evaluated to null it throws an error. So we have to check the node first every time we use length() or use a fallback in the argument:

    abc && length(abc) > `0`

    or

    length(abc || []) > `0`

    Would it be nice if it just returned null instead of throwing an error?

    Maxime Labelle
    @springcomp
    That's an interesting point. It maybe goes with one concern @innovate-invent has, with projections filtering null values. So on the one hand we have a feature that tries to protect us from nulls ; but on the other hand functions a more stricly typed. I can certainly agree that null should be considered a valid value of all types so, yes, your suggestion makes sense.
    hell-racer
    @hell-racer

    null is "falsie", so it would work with other logical expressions, e.g. (considering it will return null instead of throwing):

    length(abc) > `0` && contains(def, 'ghi') && 'yes' || 'no'

    This would correctly return 'yes' or 'no' even if some nodes are missing.

    Maxime Labelle
    @springcomp
    Yes definitely.