Question about relations query

Hi, Good afternoon from Gran Canaria.

I would like someone tell me about how Servoy handles relations or rather relation queries.

For example if I have a related table like customers_to_products, does Servoy query for the relation everytime I access to a field in products?

I mean. If in process I have to do something like:

var a=customers_to_products.prod_name;
var b=customers_to_products.prod.price;
var c=customers_to_products.prod_familyid;

how many times is the relation query executed? Is better to do something like:

var _prods=customers_to_products;
var a=_prods.prod_name;
var b=_prods.prod.price;
var c=_prods.prod_familyid;

At the same time I would like to know how Servoy handles calculations and aggregattes.
Please tell me what could improve performance.

Thanks.

You can test this easily yourself in the servoy-admin page (clear the history first)

but if you didn’t touched or showed that relation, before it is only query’d once!
If you already showed it before, it does not query at all.

Out of my head, if you touch a relation, for the first time in code, it queries also the first 10 or 20 records of that relation

Juan,

Servoy keeps a cache of related foundsets in memory, once a related foundset is queried from the server it will be reused and not re-queried.
These foundsets are cached using soft references which means that when memory is running low the foundsets are removed from the cache.

Calculations are ‘lazy’ which means that they are only executed when the value is used somewhere after which the value is cached.

When a calculation is executed, we track which data is used in the calculation.
When some of this input data is changed, the calculation is invalidated.
Only when a the calculation is needed again (in scripting or when shown in the UI) it is executed again.

Aggregates are cached with the foundset (for example orders_to_detail.count_order_detail is kept with the orders foundset) and is also executed lazily.

Rob

Thanks Rob.

I think that knowing that is good for better developing practices. Sometimes you might do something useful in a big impact in performance and other times you might not use something useful because you think that could be bad for performance.