Request - Inform Servoy Server to Broadcast Add/Del's (Long)

Classic Servoy
1

Hi (a long feature request below),

We’ve built an ~60 table ASA solution in b330 which uses all DB-managed keys, and does record adds and deletes via stored procedures; ie: does not use Servoy’s newRecord() and deleteRecord().

This allows us to build a PHP-based Web application (not the Headless Client API) accessing the same database and add/delete procedures, and gives complete separation of GUI and database.

Our problem is our procedure-added/deleted records don’t broadcast to other Servoy clients since Servoy server doesn’t know about the add/delete. We’ve used refreshRecordFromDatabase() so the client doing the add/delete is in sync with the database, but the other clients can’t be updated.

Bob Cusick has recommended (thanks again for your time, Bob!) we re-write our ASA procedures so they can be called 1) via Servoy, then return a boolean for a then Servoy-performed newRecord() or deleteRecord() if applicable, or 2) via PHP to perform the add/delete in the ASA procedure. Having Servoy do the add/deletes is needed to broadcast the changes to other clients.

We are investigating Bob’s suggested option (and having some issues we’ll post in other threads), but we’d like to request additional capability in Servoy for these reasons: 1) the complexity of our ASA procedures goes way up, and 2) we are writing code in the database specifically related to the GUI. An advertised selling point of Servoy is the strict separation of GUI and DB and is in fact a reason we chose the environment.

We’re don’t know Servoy internals, but exposing a more granular version of the headless client API’s flushAllClientsCache() seems a good direction. We’d like to programmatically tell Servoy server to update clients with adds and deletes in a db-efficient fashion. Again, we don’t know Servoy internals but it seems providing access to the broadcast process of Servoy server should be feasible, no?

We think this would speak towards 100% separation of the database from the GUI – ie: DB-managed keys, w/ stored procedure-based adds/deletes – and would be a valuable feature of the Servoy environment.

We’ll continue working though alternatives, but are eager to hear comments from Servoy on this idea.

Thanks for your time and the Servoy environment!

JDW

2

Hi,

I second this motion! :)

For different reasons, we also have the situation where records are updated, added or removed from the database though other ways than Servoy. It would be great is there would be a way to update the cached foundsets in Servoy somehow.

I see two different bits of functionality:
1- extending the Servoy DataChange braodcast functionality in such a way that if a refresh of a certain record or foundset is done through a method in a Servoy Client and changes are found, that these Changes are not only shown in the Client that initiated the refresh, but also are broadcasted to other Clients having that record/foundset cached.

2- Having some sort of mechanism that can be triggered from outside Servoy to refresh a certain record/foundset in such a way that all Clients that have this record/foundset cached are updated with the new info.

Now, with respect to the first bit of functionality: Not knowing what is under the hood of Servoy, but thinking along the lines it seems to me, this ought to be a doable thing

With regards to the second piece of functionality, there are different ways to do this, I’d think. One I can think of would be some system that allows to push PK-ID’s of new/altered/deleted records into Servoy server, through Http post/webservices or by adding them to a Servoy table, which Servoy scans for (new) entries.

Maybe there are much neater ways to achieve this second bit of functionality. If you have them, please add them to this post.

Paul

3

ALL - come to Servoy World. You’ll be happy. 8)

4

Mmm, now I’m curious… Any particular session to attend for this?

Paul

5

Isn’t Bob just the ultimate salesman :)

6

grahamg:
Isn’t Bob just the ultimate salesman :)

Yes it is! :D

7

Had a look at the RAWSQL plugin, which is what bob was referring to, I guess.

This plugin basically flushed all foundsets, which is a hefty action, from the warnings the plugin developer got about this part of the plugin API.

The requests that where made in the first two posts of this topic are a bit more elegant and efficient

1- extending the Servoy DataChange braodcast functionality in such a way that if a refresh of a certain record or foundset is done through a method in a Servoy Client and changes are found, that these Changes are not only shown in the Client that initiated the refresh, but also are broadcasted to other Clients having that record/foundset cached.

2- Having some sort of mechanism that can be triggered from outside Servoy to refresh a certain record/foundset in such a way that all Clients that have this record/foundset cached are updated with the new info.

Especially the first one, where one Client becomes aware of an external datamodification by a refresh of a record/foundset, wouldn’t it be possible to get those datamodifications broadcasted to all clients?

If this could be done, one could build the second feature himself by settign uo some sort of queueing mechanism and a batchprocessor…

Paul

8

pbakker:
Had a look at the RAWSQL plugin, which is what bob was referring to, I guess

Not necessarily … maybe someone can correct my memory because it can be awfully spotty recently … but I think I remember update broadcasting (if that’s the right phrase) being described as a feature we can expect in v3?

kazar

9

Bob?

10

Yes, it does dump the entire cache - sorry that’s the way it works…

11

So, my assumption that your comments were about the SQL plugin were right.

So, it works like that now. Any change the suggested features in this thread might be taken into consideration?

Paul

PS: One can dream, can’t he? :lol:

12

Although I’m not the one writing the code - the short answer is: not likely any time soon.

The reason is that we don’t keep track of the individual client’s cache - so we don’t know what to selectively update. All we know is that there IS a cache - so we can invalidate the entire cache.

If you want to do selective updates - then you’ll have to use the foundsetUpdater and not the raw SQL plug-in.

Sorry to “kill” the dream… :wink: