Feb 4, 2021

Jolt transform both fields required

Jolt is a JSON to JSON transformation library where the transform is defined in JSON. As an example you may want to transform the latitude and longitude fields into a location object containing those fields.

Transform
[
  {
    "operation": "shift",
    "spec": {
      "latitude":"location.latitude",
      "longitude": "location.longitude"              
    }
  }
]
Input
{
  "latitude": "41.2565",
  "longitude": "-95.9345"
}
Output
{
  "location": {
    "latitude": "41.2565",
    "longitude": "-95.9345"
  }
}

Sometimes you only want to transform two fields if both values are present. A location isn’t really a location if it only has a latitude or a longitude. In that case you can nest the transform like this.

Both Required Transform
[
  {
    "operation": "shift",
    "spec": {
      "latitude": {
        "@(1,longitude)": {
          "@(2,latitude)": "location.latitude",
          "@(2,longitude)": "location.longitude"
        }
      }
    }
  }
]

What’s going on here? Well we are mapping the latitude to a block of transform. That transform maps “@(1, longitude)” –go up a level and get the longitude field– to another block that maps up two levels to latitude and up two levels to longitude to the “location.latitude” and “location.longitude” respectively. Now we are only mapping the data if both latitude and longitude exist!

About the Author

Scott Bock profile.

Scott Bock

Principal Technologist

Scott is a Senior Software Engineer with over 12 years of experience using Java, and 5 years experience in technical leadership positions. His strengths include troubleshooting and problem solving abilities, excellent repertoire with customers and management, and verbal and written communication. He develops code across the entire technology stack including database, application, and user interface.

One thought on “Jolt transform both fields required

  1. Scott Bock says:

    See full code example with test at https://github.com/scottbock/Jolt

Leave a Reply

Your email address will not be published.

Related Blog Posts
Building Better Data Visualization Experiences: Part 2 of 2
If you don't have a Ph.D. in data science, the raw data might be difficult to comprehend. This is where data visualization comes in.
Unleashing Feature Flags onto Kafka Consumers
Feature flags are a tool to strategically enable or disable functionality at runtime. They are often used to drive different user experiences but can also be useful in real-time data systems. In this post, we’ll […]
A security model for developers
Software security is more important than ever, but developing secure applications is more confusing than ever. TLS, mTLS, RBAC, SAML, OAUTH, OWASP, GDPR, SASL, RSA, JWT, cookie, attack vector, DDoS, firewall, VPN, security groups, exploit, […]
Building Better Data Visualization Experiences: Part 1 of 2
Through direct experience with data scientists, business analysts, lab technicians, as well as other UX professionals, I have found that we need a better understanding of the people who will be using our data visualization products in order to build them. Creating a product utilizing data with the goal of providing insight is fundamentally different from a typical user-centric web experience, although traditional UX process methods can help.