JSON颠簸移位规范，用于具有不同值类型的重复键？ [英] JSON jolt shift specification for duplicate keys with different value types?

问题描述

我正在尝试创建一个将接受输入的规范

  abc：true 
 abc：{strings。 ..} 
  

并输出：

  abc：true 
 abc：{strings ...} 
  

我知道这不需要进行Jolt移位，我只需要包括它即可使我的数据段（包括 abc 键）转移并且不会迷路，

有人知道如何添加到Jolt shift规范中来执行此
（根据其值类型对2个重复键进行移位）。

解决方案

对于震荡处理器，当您尝试添加已经存在的键映射时，应用程序将为此大吼大叫。但是，对于您而言，您似乎正在处理两种不同类型的内存存储，其中1是数组，另一种是变量。出于某种原因，处理器似乎优先于数组优先于单个值，但不必担心，为此需要进行大量的工作。

1. 第一个也是最明显的解决方案是在 abc的数组索引中传递 @：& code>。
根据震动处理器的移位操作中的通配符文档，

   
   
   
   
   
   • @ 位于的左侧：表示将传递的密钥作为索引。
   
   
   • & 在的右侧：代表
   
   



与此传递的索引关联的值（如果需要，则取消引用）。这将拉取与传递的密钥关联的所有信息。 但是，这将包括所有数组值的重复，在大多数情况下，这与您首先重新映射其索引的理由背道而驰。

2. 第二种解决方法，也许最理想的方法是重新映射变量。 根据通配符文档，＃允许引用信息。在：的右侧，它用于根据在数组信息中回溯时找到的匹配数来提取索引。在我们的案例中，左侧使用的更多，这允许我们将实例值的映射硬编码到新字段

获取代码

  foo：{
 bar：{
 #lemonade：饮料 
}} 
  

发现为字段 foo的有形 value ，然后将一个名为 lemonade的值映射到一个名为 drinks的字段。这将允许您处理 abc 输出与标准数组不同的实例。 但是，这是一个硬编码，因此无法将其转换为您最初寻找的布尔值。

3. 第三个也是 最理想的解决方案 这是规避此问题的一种比较偷偷摸摸的方法，该方法是使用要转换的字段创建一个单独的索引。 有关此技术的参考和说明，请参见此处。
   以下代码：

   
   
   

   [{
operation： default，
spec：{
ref：{
True：true，
False：false
}
}
}，
{
operation： shift，
spec：{
abc：{
true：{
@（3，ref.true） ： abc
}，
false：{
@（3，ref.false）： abc
}
}
}
}，
{
operation：删除，
spec：{
ref：
}
}]

我们在这里所做的只是震动处理器，我们正在创建一个称为ref的参考索引，我们将布尔值true和false传递给它供以后使用。我们继续进行移位操作，然后继续执行示例2中的操作，方法是开始指示在父标头中出现此特定值时要执行的操作，但是我们使用了 @ 追溯到树的3个父级，并使用字段 True 和 False 将必要的布尔值附加到字段 abc 。删除 ref 字段即可整理所有内容，因此剩下的只是 abc 的正确映射。 / p>

这种方法（如果不是最优雅的话）不仅可以规避最初的问题，而且可以保留数据类型，并且可以扩展为处理各种其他值，例如整数，甚至是双精度整数，但是要进行此类工作，还需要进一步的测试和研究。

I am trying to create a spec that will take input

abc:true
abc: {strings ...}

and output:

abc:true
abc: {strings ...}

I know this shouldn't require a Jolt shift, I just have to include it so that segment of my data (both abc keys) transfers over and doesn't get lost,

Does anyone know what to add to a Jolt shift spec to do this (shift 2 duplicate keys based on their value types).

解决方案

For the jolt processor, when you try to add key mappings that are already existing, the application will yell at you for it. However in your case, it would seem that you are dealing with two different types of memory storage, where 1 is an array, the other is a variable. The processor seems to take precedence with the arrays over the single values for some reason but fret not, there are plenty of work-a-rounds to this.

1. The first and most obvious solution is passing "@":"&" within the array index of abc. According to the documentation of wildcards in the shift operations of jolt processors ,

   • @ being on the left hand side of : stands for putting the passed key as an index.
   • & being on the right hand side of : stands for the value associated at this passed index (A dereference if you will).

Together this will pull all information associated with the passed key. However, this would include a duplication of all your array values, which in most cases goes against your reasoning to remap its index's in the first place.

2. The second solution, and perhaps most ideal would be a remapping of the variables. According to the wildcard documentation, the # allows for a referencing of information. On the right hand side of a :, its used to pull an index based on the number of matches found while backtracking through its array information. The left hand side has far more use in our case which allows us to hardcode a map of an instance value to a new field

Take the code

"foo" :{
          "bar" : {
               "#lemonade" : "drinks"
}}

Upon the instance of bar being spotted as a tangible value to field "foo", you would then be mapping a value called "lemonade" to a field called "drinks". This will allow you to handle the instance where abc is being outputted differently than your standard array. However, this is a hard coding and as such it can not be casted to the Boolean values that you were initially seeking.

3. The third and most ideal solution is a rather sneaky way of circumventing this issue which is to create a separate index with the fields you want to cast to. For reference and clarification to this technique, see here. Take the following code:

   [{ "operation" : "default", "spec":{ "ref":{ "True" : true, "False": false } } }, { "operation" : "shift", "spec":{ "abc":{ "true":{ "@(3,ref.true)":"abc" }, "false":{ "@(3,ref.false)":"abc" } } } }, { "operation" : "remove", "spec":{ "ref" : "" } }]

What we are doing here is at the start of the jolt processor, we are making a reference index called ref, which we pass values of Boolean true and false to it for later use. We move on to the shift operation which we then proceed to do what we did in example 2, by starting to indicate what we do when this particular value occurs within the parent header, but instead we use an additional function of @ to trace back into the tree 3 parents, and use the reference values of the fields True and False to attach the necessary Booleans to the field abc. It tidy's everything up by removing the ref field so all that you are left with is the correct mapping of abc.

This method, if not the most elegant, not only circumvents the initial issue, but it preserves data type and could perhaps be extended to handle a variety of other values like integers or even doubles, however further testing and research would be required for such endeavors.

这篇关于JSON颠簸移位规范，用于具有不同值类型的重复键？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！