In Perspective I have a custom variable “model“ that is a dict of (currently) 34 items, each of which is a variable pulling model data from sql. I want/need these data to be available in the session. IMO it is not a huge amount of data being queried.
However it seems I have hit some kind of limit. If I add more elements to this model object, the sql does not execute and the variable returns ‘null’
Is there a limit on how much data can be queried? limit on number of such queries? Is there a setting I can change?
Perspective has to JSONify any objects you assign to Perspective session/view/component properties.
Each assignment will, for any variables that aren't marked private, generate a message to the browser with the munged content. If that message is too large, there will be an error and the assignment will fail.
Not sure what is going on for you, as I am not a mind reader, and you have shared no code of any kind.
Within this object I have created member variables, which are mostly lists. These all have query bindings to tables in a mysql database
There are currently 34 such member variables, and growing. I need to add more
When I add additional variables they do not update, ie it seems the query binding on the additional variables do not execute
Of the 34 existing variables, only 32 get values from the database. The other 2 return null. I figure there is a limit (somewhere) of 32.
So what to do? Create an object called model_part_2? Most annoying
If you open one of the two+ failed bindings within Designer, are the queries executed successfully there?
If possible, I recommend you create and execute a single query which requests data for all 34+ groups of data, then (perform any post-processing needed and) return the results in the format your app requires.
There are limits to number of simultaneous database connections. Excessive queries, combined with lengthy query times and timeout limits may be contributing to your observations at runtime.
For starters, how about posting formatted code for one of your queries, provide the size of your results set for that query, how the queries differ between bindings, and a screenshot (or copy the object and paste the formatted code) of your resultant object?
I can guarantee you there's no explicit limit anywhere in code of the number of elements in a Perspective 'object' type property - or rather, if there is, it's a fundamental Java collection limitation that will be a power of 2 (minus one) like 2,147,483,647, not 32.
It is possible, depending on the depth of the data within those 32 keys, that what you're encountering is an issue with the backing Websocket between the Perspective "backend" (on the gateway) and the "frontend" (wherever the session is actually running) synchronizing property values. This websocket is deliberately set out of the box to a relatively low size (still megabytes) so that someone writing a script that sends huge volumes of data will have to deliberately raise this limit, rather than have it cause performance issues for their entire gateway.
If this is what's happening, it should be explicitly clear from your gateway logs - it's not a 'quiet' failure condition.
As Phil mentioned - the simplest solution (if these are custom properties, which almost by definition can only be interacted with from the backend) is to mark the entire root property as 'private'. This prevents us from synchronizing it to the frontend entirely, work which is basically guaranteed to be pointless for custom properties which can only be reached by scripts/expressions/bindings that are evaluating on the backend anyways.
