gdurniak:
Perhaps I had it backwards …What we need is an OnDataBroadcastReceived() Method
greg
and that what?
If that happens we call that and we don’t do anything? That would completely kill the system.
because we do many things under the hood to make sure that all the caches, all the related foundsets are up to date.
You can’t do that in that method.
mboegem:
I can’t remember seeing this behaviour.
If I’m not mistaken the pk has to be in a foundset before getting it in the onDataBroadcast event.
how on earth would that work then??
If somebody updates or inserts a new record that now suddenly belongs to a related foundset that you already have loaded in?
How does that record that come into that related foundset if we don’t get any event for it?
So we have to get everything of that table, else we can’t make sure that all the related foundset are really in sync with the database.
it seems one solution would be to let us “catch” any databroadcast received, then write our own method to refresh the screens ( or do nothing )
that is not possible now ( which may be a “bug” )
please note that your current databroadcast setup DID kill my system, with a flood of activity
but if there are databroadcast updates you must do “under the hood”, then we do have a problem
greg
and then what?
If that happens we call that and we don’t do anything? That would completely kill the system.
gdurniak:
it seems one solution would be to let us “catch” any databroadcast received, then write our own method to refresh the screens ( or do nothing )
its not about refreshing the screen for us. Its about data consistency and because of that data is updated and that will fire some events that will update the screen
But that is only a result of, not the actual thing where we need it for.
Also i think in this thread there is talk about that you get pk’s that are not meant for this client anyway.
And you want to stop that. But how to do that? How do you know in the client if you get a pk that is a result of an update that you don’t need that one?
Then you need first to have the full records data before you can see that it is really something for another tenant, so checking it on the client is not a good idea…
This is more like a server side filtering of that. So that the server already can decide should i send this data broadcast to this client with that clientid.
In my solution, every user updates their own set of records, by selecting a global job number
it seems checking a databroadcast received on the client to see if the PK ( or job number ) is in use would be less overhead
greg
Also i think in this thread there is talk about that you get pk’s that are not meant for this client anyway.
And you want to stop that. But how to do that?
When the cracks talk contrary like this…
mboegem:
pbakker:
Yes, this is expected: DataBroadcast works on table level: if your client has a foundset in memory based on table x, then it will receive databroadcasts events for all create/update/delete activity in that table.I can’t remember seeing this behaviour.
If I’m not mistaken the pk has to be in a foundset before getting it in the onDataBroadcast event.
… I just start wondering and test and try again…
maybe this makes it more clear: The databroadcast indeed looks, if the pk is in my foundset, but in this specific situation:
The difference to my first post is:
In this test-case I had following situation:
it simple, if a table is touched by a client (it did a query on it, got some records)
then it will start receiving databroadcasts for that table.