Passing array output from a query into an addon input

aemondis

Has anyone discovered a way to pass a list of values directly from the output of a query into an addon? I have an addon which does some aggregate calculations, based on an array of values (which it looks up) for the input. The problem is though - I can't find any way to pass ANY list value as an output into the addon (it only seems to allow single values), since fields returning a list are simply not listed as available options?

It seems to be achievable using a variable, but that then adds a bunch of overhead since I will need to do the variable population within a loop. If I could simply pass the array straight to the addon, I could eliminate all loops from my code and simplify things dramatically.

Any thoughts, or is this a limitation of Xano?

aemondis

For those who have encountered this limitation - there is a workaround, but it's not pretty. The fastest (lowest overhead) way I found to achieve it was a "for each" loop, and a separate array variable to hold the output object with a new custom path to hold the calculated aggregate.

You will need the additional variable in this example, as there is a strict schema on data retrieved from the DB and stored as an object - which won't allow a custom path to be added, as I discovered the hard way.

I'd love to see support for Xano to handle lists as an input to an addon, but if this truly is a limitation - I have no idea why the ability to allow addons to support a list as an input is even there, since it simply doesn't seem to be possible. I spent hours trying various possible combinations, and nowhere could I find a way to inject a list into an addon input…

Ray Deck

It looks like maybe you are trying to use an addon for calculated summaries, rather than augmenting with additional data. These are similar problems - both augmenting the original data set - but not the same. I generally use the function stack for calculations based on the input data (e.g. map/reduce), and use addons for getting more data into the input for the rest of the function stack.

There's not a lot of profit in having Postgresql do calculations for you, except when you are reducing from a list into a summary (e.g. counts, averages, etc) to prevent a giant mass of data from having to travel from sql-land into xano-land. It's all the same CPU doing the work.

If you have a clear vision of what you want the whole query to do, you can make complex custom SQL through direct database query functionality. This basically gets around the limitations of addons etc, and can be handy for complex queries that get cumbersome in Xano's no-code query builder.

But in general, I return to the separation of concerns mental model: get all the data I want from the database query, and then produce calculations and summaries through the function stack. When used in combination, we get a lot of power without a lot of ceremony!

aemondis

@Ray Deck completely agree, this is an area I mull over with almost everything I do - design things in a way that I am not unintentionally creating a bottleneck that will bite me as I scale.

The main reason I was trying to achieve this is due to the calculation involving data from several tables, over joins that involve NULL. I can do this pretty simply with an addon that aggregates these scores using an EVAL, leaving just a single value returned to the API/processor and the DB doing what it does best - retrieving and matching up rows of data. Without the addon, I instead need to do this calculation in the API - meaning I am retrieving data necessary for ~42 values for every item, then having to loop through it on the server. This obviously isn't going to scale nearly as well, especially since that list of values is multiplied by at least 3 for every parent item. So it will definitely not scale in the current form nearly as well, but I have optimised it as best I can currently given the limitation.

I might play around with the direct DB queries - as I was a DBA in a prior life and spent an inordinate amount of time understanding data patterns and the query engine to determine index design, optimising schema design and even denormalising where called for. I wasn't aware I could actually do this on the launch plan.

How I'd love to see a simpler aggregate capability in Xano that can be applied to a list of data in the output…