# Flex Repeater: how to bind instances properties **URL:** \ **Category:** Ignition\ **Tags:** ignition81\ **Created:** [March 29, 2022, 2:23pm UTC](https://forum.inductiveautomation.com/t/flex-repeater-how-to-bind-instances-properties/57759 "2022-03-29T14:23:36Z")\ **Posts on this page:** 9\ **Page:** 1
**Author:** ![pgmo](https://avatars.discourse-cdn.com/v4/letter/p/d07c76/32.png) [@pgmo](https://forum.inductiveautomation.com/u/pgmo)\ **Post date:** [March 29, 2022, 2:23pm UTC](https://forum.inductiveautomation.com/t/flex-repeater-how-to-bind-instances-properties/57759/1 "2022-03-29T14:23:36Z")
I’m trying to build a recipe editor with a combination of **Flex Repeaters**. My recipe is made up of steps, each having its own parameters. Recipe values come from a query on the database, which query I’d like to be **unique across the view lifecycle**. At the same time I need to break the editor into groups, one group for each step, but I wouldn’t like to query my database so many times as the number of my steps, one time per group. Therefore I created a view called _RecipeEditor_ with a Flex Repeater, which repeats a _SingleStepEditor_ view as many times as the number of steps. Each _SingleStepEditor_ is a Flex Repeater itself: it should receive the result of the main big query - which I bound to a custom property in the root container of the main view - and build the list of parameters pertaining to the step through a transform. What I can’t manage to do is to pass the main big query to the Flex Repeaters.I’ve tried with messaging on a _property changed_ event script on the _big query_ custom property but with no success - and moreover I’m not sure it’s a best practice. Maybe session properties is the correct way? Any suggestion is appreciated. Thanks, regards ---
**Author:** ![ryan.white](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/ryan.white/32/73193_2.png) [@ryan.white](https://forum.inductiveautomation.com/u/ryan.white)\ **Post date:** [March 29, 2022, 4:10pm UTC](https://forum.inductiveautomation.com/t/flex-repeater-how-to-bind-instances-properties/57759/2 "2022-03-29T16:10:52Z")
This sounds similar to something that I’ve been working on. How often are the values in the DB changing? Are they only changing when you are writing to them with this editor? If they only change when someone changes them via editor, you can add a message that gets sent on edit, which tells all other sessions that have the same recipe open to update their values, instead of relying on a query firing every x seconds. Helps to reduce the load, so this is what I use. The way I handle my case is to transform the data from the big query into a list of dictionaries, with the normal expected keys for the first flex repeater. While I’m doing this transform, I then also add an ‘Instances’ key to each of the dictionaries in the list, which contains another list of dictionaries, all with the expected keys/data for the second level flex repeater of that step. You can then either put this list of dictionaries into a separate session variable or just keep it on the original session variable. You then bind the first flex repeater’s Instances property to this session variable. The view that contains the second flex repeater will then need a view param called ‘Instances’. This should be bound to said view’s Flex Repeater’s Instances prop. Once that is complete, it should work as you expect. Each time the query fires it will rebuild the list of dictionaries, and both levels of flex repeater should get their needed data. ---
**Author:** ![lrose](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/lrose/32/62724_2.png) [@lrose](https://forum.inductiveautomation.com/u/lrose)\ **Post date:** [March 29, 2022, 5:11pm UTC](https://forum.inductiveautomation.com/t/flex-repeater-how-to-bind-instances-properties/57759/3 "2022-03-29T17:11:53Z")
> [@pgmo](#): > > which query I’d like to be **unique across the view lifecycle** I don't understand what you mean by this. Why would the query be unique? I would expect the query to be parametrized and for the parameters to change based on the step, but it sounds like you want the entire query to change, which doesn't seem correct to me. I would build your SingleStepEditor view with a parametrized query (Ideally a Named Query). Then in the Flex Repeater you can send those parameters through to the embedded view. ---
**Author:** ![pgmo](https://avatars.discourse-cdn.com/v4/letter/p/d07c76/32.png) [@pgmo](https://forum.inductiveautomation.com/u/pgmo)\ **Post date:** [March 29, 2022, 7:48pm UTC](https://forum.inductiveautomation.com/t/flex-repeater-how-to-bind-instances-properties/57759/4 "2022-03-29T19:48:29Z")
> [@lrose](#): > > I would build your SingleStepEditor view with a parametrized query If you do like that, each _SingleStepEditor_ will fire its query against the server to fetch the parameters it needs and that's just what I want to avoid. Suppose you have 200 steps: each time you open the view you load your server with 200 queries. However, since the recipe params table is normalized, you just need one query to fetch all recipe parameters at once. Moreover if you need to refresh the recipe data from server, if you have just one query you need to run just one _refreshBinding_ and all _SingleStepEditor_ instances will get updated accordingly. ---
**Author:** ![pgmo](https://avatars.discourse-cdn.com/v4/letter/p/d07c76/32.png) [@pgmo](https://forum.inductiveautomation.com/u/pgmo)\ **Post date:** [March 29, 2022, 7:52pm UTC](https://forum.inductiveautomation.com/t/flex-repeater-how-to-bind-instances-properties/57759/5 "2022-03-29T19:52:11Z")
Hi ryan, this afternoon I did just what you are suggesting and it works. I’m wondering if in _Perspective_ you have anything like **Vision** _CellUpdate_ bindings which could be of help. ---
**Author:** ![ryan.white](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/ryan.white/32/73193_2.png) [@ryan.white](https://forum.inductiveautomation.com/u/ryan.white)\ **Post date:** [March 29, 2022, 8:03pm UTC](https://forum.inductiveautomation.com/t/flex-repeater-how-to-bind-instances-properties/57759/6 "2022-03-29T20:03:04Z")
What’s the use case? Are you trying to have the query refresh when you enter something in a field? I’m not super familiar with vision equivalents in perspective. I’ve also not really used repeaters in Vision. Edit: Just looked these up in the documentation, not sure of any equivalent in perspective. Are you trying to avoid rebuilding the entire dataset for 1 value update? ---
**Author:** ![pgmo](https://avatars.discourse-cdn.com/v4/letter/p/d07c76/32.png) [@pgmo](https://forum.inductiveautomation.com/u/pgmo)\ **Post date:** [March 29, 2022, 8:29pm UTC](https://forum.inductiveautomation.com/t/flex-repeater-how-to-bind-instances-properties/57759/7 "2022-03-29T20:29:04Z")
As I wrote in my reply to irose, my aim is an editor that loads SQL Server as little as possible, above all while fetching data. Therefore I’d like to define a unique query anywhere (session, main view, …), the result of which must be passed to all the sub-editors by using bindings if possible. The idea to use a flex repeater to instantiate each single step editor is due to its very nice feature of building UIs based on queries: as a consequence if some steps/parameters add to the recipe in the future, I’ll have non need to edit the view again, because query+flexrepeater will do the magic. ---
**Author:** ![ryan.white](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/ryan.white/32/73193_2.png) [@ryan.white](https://forum.inductiveautomation.com/u/ryan.white)\ **Post date:** [March 29, 2022, 8:55pm UTC](https://forum.inductiveautomation.com/t/flex-repeater-how-to-bind-instances-properties/57759/8 "2022-03-29T20:55:20Z")
Single session property with parameterized named query binding and transform script will probably be your best bet for minimal load on your SQL server, since you would be only running 1 query, instead of however many per view/repeater. For even less load, don’t have the query fire outside of initial data load (When you’ve selected which recipe to view/edit) or unless something else signals via message that there has been a change to the data, either from you editing via your interface or otherwise. If you don’t mind me asking, why are you so concerned with SQL load? 5 or 6 queries per second per session with several sessions won’t really hurt most mid to enterprise level systems. If your poll rate is something even lower then its even less of a concern. This project doesn’t seem like it would have many sessions open at once anyways. Most of our databases are running around 10/s, spiking to 30-80/s depending on certain applications, but I know through unfortunate circumstances it can handle ~400-500/s before it starts to fail, even then it can trudge through until ~800/s, which is when we start seeing complete loss of comms. ---
**Author:** ![pgmo](https://avatars.discourse-cdn.com/v4/letter/p/d07c76/32.png) [@pgmo](https://forum.inductiveautomation.com/u/pgmo)\ **Post date:** [March 30, 2022, 5:58am UTC](https://forum.inductiveautomation.com/t/flex-repeater-how-to-bind-instances-properties/57759/9 "2022-03-30T05:58:34Z")
Yes, you are right, SQL Server can do much more work then a bunch of some hundreds of queries. But for me it’s a matter of design: - query as less as possible - single source of truth - binding refresh with just one command - don’t waste bandwith in case your project has still to grow