I have been intrigued by the suggestion about some sort of call-back macro implementation and it suggested to me that perhaps the following would address that and many other possible uses.
The idea of this feature request is to request the ability to have fields in the Custom table which are calculated fields. It is not really a new concept for GSAK because there are already many calculated fields in the cachesall view.
I envision an implementation of this idea as follows (this just to clarify the idea, not to request this particular implementation):
On the dialog where the custom field is created, provide additional configuration where some sort of sqlite Update could be specified. As I understand it, sqlite update looks (generically) like this:
So the custom field edit/create dialog would need edit boxes where the user could provide expression1 and expression2.
Internally GSAK would assemble the sqlite statement (using "custom" as the table name and column-name would be the custom field that is being configured). This would be called whenever a recalculation is desired. I know that there is already an internal set of calculated fields. My sense is that this would be similar to those in terms of when and how to do the recalculation (and custom table updates would follow those).
Performance issues would be the same as those except Clyde has no opportunity for optimization. I suspect we would need some sort of test button to check a proposed formulation so that we can judge whether the resulting speed hit might be acceptable.
The idea of this feature request is to request the ability to have fields in the Custom table which are calculated fields. It is not really a new concept for GSAK because there are already many calculated fields in the cachesall view.
I envision an implementation of this idea as follows (this just to clarify the idea, not to request this particular implementation):
On the dialog where the custom field is created, provide additional configuration where some sort of sqlite Update could be specified. As I understand it, sqlite update looks (generically) like this:
| CODE |
UPDATE tablename SET column-name=expression1 WHERE expression2 |
So the custom field edit/create dialog would need edit boxes where the user could provide expression1 and expression2.
Internally GSAK would assemble the sqlite statement (using "custom" as the table name and column-name would be the custom field that is being configured). This would be called whenever a recalculation is desired. I know that there is already an internal set of calculated fields. My sense is that this would be similar to those in terms of when and how to do the recalculation (and custom table updates would follow those).
Performance issues would be the same as those except Clyde has no opportunity for optimization. I suspect we would need some sort of test button to check a proposed formulation so that we can judge whether the resulting speed hit might be acceptable.