Skip to main content
Solved

JSONFragmenter "Prefix New Attribute" not working. Bug or my fault?

  • October 28, 2024
  • 2 replies
  • 76 views

ecx
Supporter
Forum|alt.badge.img+6

Title says it all, 

Basically I have a workflow:

Adding a prefix to the new attribute results in the new attribute not to have any values.

Running with prefix:


Running without prefix:

 

 

Also if I add a prefix, for example _, and have a new field I wish to extract, i.e. “ID” which should result in a new column “_ID” with values, it instead replaces the original id field with the new values, totally ignoring the requested “_” prefix. 

Workaround is to rename the original values with a prefix before extracting second set of values from nested json.

Best answer by ecx

Hi,

I understand the first one. Safe could potentially add the prefix to any attribute to expose. There might be a reason why they don’t, but also maybe it is just overlooked. As it stands, you need to prefix the attributes to expose with the same prefix you put in the input above.

 

For the _id example, I was not able to replicate the issue you mentioned around it not honoring the prefix in 2024.0 or 2023.2

 Could you provide an example?




Ah yes, I think I understand now. 

I initially thought the ‘prefix new attributes with’ and the ‘attributes to expose’ were related, i.e. a newly exposed attribute would have the prefix applied to it. But I imagine that is not how it works.

That helps answer the second question as well. If a field named ID exists, and then another field with name ID is exposed, the original ID is replaced with the newly exposed ID. The prefix has nothing to do with the newly exposed attributes, only the attributes spat out by the json query will have a prefix.

Thanks!

 

This post is closed to further activity.
It may be an old question, an answered question, an implemented idea, or a notification-only post.
Please check post dates before relying on any information in a question or answer.
For follow-up or related questions, please post a new question or idea.
If there is a genuine update to be made, please contact us and request that the post is reopened.

2 replies

todd_davis
Influencer
Forum|alt.badge.img+23
  • Influencer
  • October 30, 2024

Hi,

I understand the first one. Safe could potentially add the prefix to any attribute to expose. There might be a reason why they don’t, but also maybe it is just overlooked. As it stands, you need to prefix the attributes to expose with the same prefix you put in the input above.

 

For the _id example, I was not able to replicate the issue you mentioned around it not honoring the prefix in 2024.0 or 2023.2

 Could you provide an example?


ecx
Supporter
Forum|alt.badge.img+6
  • Author
  • Supporter
  • Best Answer
  • October 30, 2024

Hi,

I understand the first one. Safe could potentially add the prefix to any attribute to expose. There might be a reason why they don’t, but also maybe it is just overlooked. As it stands, you need to prefix the attributes to expose with the same prefix you put in the input above.

 

For the _id example, I was not able to replicate the issue you mentioned around it not honoring the prefix in 2024.0 or 2023.2

 Could you provide an example?




Ah yes, I think I understand now. 

I initially thought the ‘prefix new attributes with’ and the ‘attributes to expose’ were related, i.e. a newly exposed attribute would have the prefix applied to it. But I imagine that is not how it works.

That helps answer the second question as well. If a field named ID exists, and then another field with name ID is exposed, the original ID is replaced with the newly exposed ID. The prefix has nothing to do with the newly exposed attributes, only the attributes spat out by the json query will have a prefix.

Thanks!