LINQ-like query nodes

[RogerSaele]

It would be useful to have something similar to C#'s LINQ in LabVIEW. Basically a way to "query" array of clusters/objects (and for some nodes even array of strings/numbers/whatever) without needing to use loops. I imagine nodes similar to invoke nodes, something like the below examples:

If one wired an array of clusters one should be able to choose from the elements in the cluster, like an Unbundle By Name node. For the Where node one should subsequently be able to select how to filter based on the data type of the selected element. For example: Equals, Greater Than, Less Than, Greater or Equal to, In Range, etc. for numbers. Equals, Contains, Starts With, Ends With, etc. for strings.

[NickNZ]

Only the Select option at top right is not modifying the input array. 

Need to discuss the pros / cons of the top right output being modified. (This implies a branch in the input array wire before this node). 

I am thinking top right should always equal input array, and add the output on bottom with the resulting value, or the rows starting with the arrow have the output. (Not sure what the arrow on left side is adding). 

Colors mismatch between Sensor.Tag string and blue count numeric. 

Perhaps this is better?

[RogerSaele]

Or perhaps like this:

[RogerSaele]

Really I was thinking they should be chainable like so:

But chaining vertically is also an option, perhaps like:

[AristosQueue (NI)]

> am thinking top right should always equal input array

If the top-right output should always equal the input array then we should eliminate the top-right output. By-value carry through terminals on nodes are generally a problem for LabVIEW as they encourage needless serialization and prevent many compiler performance optimizations by forcing preservation of values that don't need preservation. We have been wiping out such terminals from as many locations as possible. The lone exception is when a by-value piece of data is acting as a reference, such as a DAQ channel name (string)... in those cases, the carry through is for the same reason we carry through refnums: there are off-diagram changes that need serialization. None of that applies in these array cases.

[RogerSaele]

If the top-right output should always equal the input array then we should eliminate the top-right output. By-value carry through terminals on nodes are generally a problem for LabVIEW as they encourage needless serialization and prevent many compiler performance optimizations by forcing preservation of values that don't need preservation. We have been wiping out such terminals from as many locations as possible. The lone exception is when a by-value piece of data is acting as a reference, such as a DAQ channel name (string)... in those cases, the carry through is for the same reason we carry through refnums: there are off-diagram changes that need serialization. None of that applies in these array cases.

Awesome, then my initial suggestion and horizontal chaining would be the way to go.

[BertMcMahan]

While I've never built one, this seems like something you could do with an Xnode. Anyone with more experience there care to comment?

[wiebe@CARYA]

Yes, with XNodes it would be feasible. I'd count on at least a few weeks of development though. Just for a first mock up, basically a proof of principle. And I've done XNodes before... XNodes aren't easy. This project won't be trivial. 

[Mads]

This would be nice to have natively, for optimal performance.

Until then, check out this:

https://lavag.org/topic/15857-cr-sqlite-library/page/9/?tab=comments#comment-137142