Is it possible to use native JSON primitive to parse this?

[airalex1919]

Hey all,

So I'm currently using InfluxDB (a time-series database) to store all of my measurement data. I have developed a tool, using LabVIEW, to provide users with access to this data through a nice interface. This tool uses the InfluxDB's Restful API to query data, which responds in JSON format. I have used other toolkits, such as JKI JSON, to tackle the issue I'm having, but these toolkits are MUCH slower that the native LabVIEW "Unflatten JSON String", in my experience. And since I am often posting requests for hundreds of thousands of points, this is no good. So, here is an example of a JSON string response for such a query:

{
	"results": [{
			"statement_id": 0,
			"series": [{
					"name": "ac_phase3",
					"columns": ["time", "value"],
					"values": [["2018-09-19T23:00:12.63546368Z", 0.07106], ["2018-09-19T23:00:12.637463552Z", 0.235248], ["2018-09-19T23:00:12.639463936Z", -0.011033], ["2018-09-19T23:00:12.641463808Z", -0.093127]],
					"partial": true
				}
			],
			"partial": true
		}
	]
}

Take notice of the 2D array "values". Each row contains a timestamp(string) AND a value (DBL). This structure is not possible in LabVIEW, without the use of clusters (which reflects a different JSON structure). Technically, a 2D array of variants would be the most accurate representation, but the VI breaks when I do this (JKI toolkit does not, but again it's really slow). I would like to be able to use this native VI, because it is fast! However, I don't see a way of getting this to work, efficiently... Is there something I can possibly be missing? Would love to hear some other ideas. I know that I can write something up in Python to handle this structure, and pass it into LabVIEW, but I'd like to avoid that, if possible (but will certainly do so, if it comes down to it). Thanks!

-Alex W.

[drjdpowell · Accepted solution]

Try JSONtext.  

[airalex1919]

Good suggestion. Didn't get a hit for that using VIPM, should have looked around more. I'll give it a shot and get back to you. Thanks again.

[airalex1919]

And I just realized the reason I didnt see JSONtext in VIPM is because its not supported for LV2016... Guess I'll give it a try in LV2018, and if it works well, I'll upgrade everything else.

[JÞB]

---

@airalex1919 wrote:

Good suggestion. Didn't get a hit for that using VIPM, should have looked around more. I'll give it a shot and get back to you. Thanks again.

---

It may be part of core LabVIEW faster than you think.....

It is a really nice parser he wrote 😉

It should be able to be backsaved for 2016.... is there a reason I am missing? Or are you dependant on type malleability that is not available in 2016?

[airalex1919]

I just wasn't sure if I could back save it, but it appears I can. This is excellent, just what I needed! Thanks!

[JÞB]

---

@airalex1919 wrote:

I just wasn't sure if I could back save it, but it appears I can. This is excellent, just what I needed! Thanks!

---

Actually  that question was for the other contributor, who wrote the toolkit.

I thought it might be backsaveable to 16 but haven't gone deep diving into it.   Now I know 

[airalex1919]

I can confirm that it is NOT back-savable. I assumed you were suggesting it was, just a small miscommunication. I built up the VI I needed in 2018 and tried to save for 2016, and unfortunately it does not work.

However, I can say that the functionality of this toolkit is exactly what I am looking for, and fast! Therefore, I will likely just continue development of this application in 2018.

Thanks,

Alex W.

[drjdpowell]

---

@JÞB wrote:
It should be able to be backsaved for 2016.... is there a reason I am missing? Or are you dependant on type malleability that is not available in 2016?

---

I wouldn't recommend using the VIMs before 2017, because of their newness.  I encountered and helped NI fix a bug or two while developing this package.  But the VIMs in JSONtext are just "syntactic sugar" that wrap Variant-based subVIs that were originally developed in 2015.  Theoretically, one should be able to backsave everything but the VIMs and then just use Variants.  But I'd recommend upgrading LabVIEW instead.

[airalex1919]

---

@drjdpowell wrote:

---

@JÞB wrote:
It should be able to be backsaved for 2016.... is there a reason I am missing? Or are you dependant on type malleability that is not available in 2016?

---

I wouldn't recommend using the VIMs before 2017, because of their newness.  I encountered and helped NI fix a bug or two while developing this package.  But the VIMs in JSONtext are just "syntactic sugar" that wrap Variant-based subVIs that were originally developed in 2015.  Theoretically, one should be able to backsave everything but the VIMs and then just use Variants.  But I'd recommend upgrading LabVIEW instead.

---

So I was trying to use "From JSON Text.vim", which prevented the back saving, as you stated. So I switched to the "JSON text to Variant.vi" and it backsaved no problem, at least it seemed so... When I tried to open it in 2016, I immediately got a notification stating that I need to install the JSONtext package. At the end of the day, I upgraded to LV2018 anyways, and my application performance is wonderful. Was just curious to see if this would work.

Best wishes,

Alex W.