Hello Dojo,
We currently have GQI query that is merging a table from multiple elements running the same driver and then filtering it down to only show related rows. These related rows will always be from one source, so would it be better to use an Ad Hoc Data script and pass that element ID as a parameter? This way we are only requesting data from one element as opposed to sending the request to all of them. This would of course be using the GQIDMS class and using SLNet calls to retrieve the table data.
Also, does GQI use the GQIDMS class in the background? So if that is the case, then using an Ad Hoc script would be the same as using a GQI query, just with a reduced source data set.
Hi Gabriel,
Normally built-in data sources are preferred over an ad-hoc implementation. Because, for built-in datasources, we have optimized certain operations. For example, if a filter/sort operation is applied to the query we can (if supported) forward that to the database.
If I understand your use-case correctly, then you are currently using a 'Get parameters for elements where' query followed by a 'filter on ElementID' operation? If that's the case then in GQI we aim to send a request to that single element only. Unfortunately we still have an open task (DCP193453) for this exact case.
Since you want to request data from one element, why can't you use the 'Get parameter table by ID' data source?
GQI core uses the same way of comminicating with SLNet as the GQIDMS class (GQI core creates that object). Except it can do some additional optimizations which are currently not yet possible within an ad hoc datasource. For example, in certain use-cases GQI can query multiple elements in paralell instead of in sequence.
Best regards,
Ward
Thank you for the clarification. Now I understand why you can’t use the ‘Get parameter table by ID’ data source.
GQI core also applies, based on the operations added to the GQI query, a fullFilter to the SLNet message. So that would be the same as what you would do in an ad hoc data script. Except that GQI core will do this in a generic way and that it will also add sorts/ column selections to that message (if the message supports this) if applicable (if a user adds such an operator to the query).
According joining another table it is hard to tell the performance difference between a built-in data source and an ad hoc script. Because for that I would require more insights in the actual setup (what tables, type of join, additional operations…)
Thank you for all the information Ward, this helped me tremendously.
For our use case, we want the user to be able to see all interfaces associated to any selected linecard in the system, so the data can exist in any of the elements that we have. That is why we are unable to use the Get Parameter table by ID query since we do not know which element we need to query until the linecard is selected.
Another potential complication is we plan on joining data from another table from another driver in the future, and have already noticed increased latency in the operation, even with the row by row option. So we thought maybe using the AdHoc option with the new GQIDMS object could be an efficient solution to only request the needed elements, but wanted clarification/verification that we are using it correctly.
Now when you say that when filtering the operation can be forwarded to the database, is that generally significantly more efficient than using the fullFilter SLNet call? Or are the improvements negligible when requesting table data from two elements? Since that is the way we were planning on gathering the necessary rows, instead of parsing through the entire table to get the rows that we want.