Page History
...
Setting | Default Value | Description |
---|---|---|
servoy.foundset.pkChunkSize | 200 | Chunk size for foundset PK retrieval |
servoy.foundset.chunkSize | 30 | Chunk size for record data retrieval |
servoy.foundset.initialRelatedChunkSize | 2 * servoy.foundset.chunkSize | Chunk size for related record retrieval |
servoy.foundset.statementBatching (since 2020.12) | false | This only works for inserts of records that are after each other (without another record from another datasource in between). It does now have side effects: In statementBatching if you insert 10 records of the same datasource, that is now always then also in a transaction (not depending if you started a transaction) because it goes into the same (single) batch statement. Because its now a transaction and a single statement to the db server, no matter if you are your self already in a transaction or we do it automatically now, if something goes wrong in 1 of the records, all records are failed, because databases don't tell us which one really failed, we would know this previously, and nothing is inserted That nothing inserted was already the case in transaction mode, but this is with this property to true different in none transaction mode, which did do the inserts until the failure and now it fails the same as in transaction mode. |
servoy.foundset.loadRelatedRecordsIfParentIsNew (since 2020.12) | false | By default Servoy will not query for related records if the relation is a pk → fk relation. So if the relation has on the primary side at least all the primary keys specified. Because this scenario should already not be possible in a good designed database (if there is a fk→pk constraint specified on the child table). Child records should not already exist if there is no Parent record already. So Servoy does not ask the database for data in this scenario. Related lookups on not yet saved Parent records should only be used to make related records, not to expect to get data. By setting this property to "true" you can force Servoy to query for data even for such scenario's |
The values can be modified in an attempt to increase performance. The optimal values differ per application, thus no guidelines are available for alternative values. Tuning needs to be done by altering the values and monitoring the performance afterwards. The defaults are set based on averages.
...