rossent wrote:The notifyDataChange is really for the Application Server which keeps the data cache. With that respect, it must affect not only the "other" clients but also the client which makes that call (similar to what the flushAllClientCache does) - that actually is part of the API documentation and is quite logical.
No, this is incorrect. The Application Server doesn't keep the data cache. The client keeps the cache. plugins.rawSQL.notifyDataChange is telling the Application Server, to notify the Clients to have the Clients update their cache. So, in your scenario, you asking the client, to notify the server, to then have the server, notify the (same) client to update its cache. That's illogical.
rossent wrote:The table events are the perfect place for this notification to take place. This way the code which notifies about the changes is completely agnostic of how the changes are actually made and ensures that the notification will always be sent. This also makes the code which changes the data completely agnostic of any other code which could be using the views based on the changed tables. I think you would agree that the single responsibility principle is a proven concept for good programming.
single responsibility principle is a great. I would disagree that the table events meet this criteria. You've decided to use SQL Views. What your missing is some place in your application where you keep track of the relationship between your base tables and the Views. For example, somewhere you must store in a configuration area that if Table W, Column X, or Table Y, Column Z changes, then you need to update the SQL View. So you need to do a refreshRecordsFromDatabase to update the current client, plus a plugins.rawSQL.notifyDataChange to notify other clients.
rossent wrote:And finally, using the notifyDataChange is better in terms of performance because it actually does not fetch anything from the database - it only tells the server that if any client asks for the records with those particular PKs, it should fetch the data from the database and not from its cache - and the point which you and Nicola perhaps are missing is that specific if.
Thats also incorrect. A notifyDataChange will tell all the clients with those records in their cache to update their cache, which results in those clients doing another call to the DB to update their cache.
rossent wrote:And the part where you suggest using web services or other headless client to call the notifyDataChange outside the current session is just a total waste of Servoy licenses and an unnecessary complication for the scenario which I described. Besides, it will not resolve the issue which started that whole discussion.
Yes, that is the lazy approach, but it would solve your problem. If I were you, I'd considering building a new DB scope with something that holds some configurations about which changes to the real backend tables should result in updating the view. Then when you save data, do something like scopes.db.saveData() instead of Servoy's default saveData call. Then you would be able to take a look at which records/tables are being modified in the save, and then you would know when you need to do a refreshRecordsFromDatabase and plugins.rawSQL.notifyDataChange to update the cache of the View. This would also give you some possible performance increase, as usually a View is built across multiple tables, so if changes are made to several tables that make up the view, you'll be able to do 1 refreshRecordsFromDatabase and 1 plugins.rawSQL.notifyDataChange call. With table events, you could be triggering that multiple times.
You might want to take another look at the Docs which outline how the caching and broadcasting works:
https://wiki.servoy.com/display/DOCS/Wo ... lientCacheClient Cache
A Servoy client instance keeps track of which database records are in use. This is called the Client Cache and it optimizes performance by reducing the number of queries made to the database. Records are tracked by primary key. The first time the contents of a record are accessed, the Application Server must issue a query to the database on behalf of the client. The values for all of the columns of the record object are held in memory and therefore, subsequent access of the record will not produce anymore queries to the database. The user experience is greatly enhanced as one can browse quickly between forms and cached records.
A record may fall out of the cache gracefully to conserve memory and is automatically reloaded the next time it is accessed. This happens at the discretion of the client's caching engine, which is highly optimized. Relieved of the burden of managing memory, the developer can focus on more important things.