> Your solution seems fine, although not all the details are clear. Why should you roll back that view transaction, what is the purpose of comitting it?
I see, so I just drop the transaction? Don't I have to either rollback or commit it?
Let's take a step back and explain the use case:
1) The client loads a view from the database.
2) Each view is a 'projection', or 'lens', or 'reactive' view over one or more entity classes.
3) After that, the client is reactive, ie: reacts to changes in the database.
4) The client sends requests to server, which makes changes to the database.
5) The server pushes changes to the client which updates its view.
There are plenty of reactive user interface libraries, knockoutjs, Vuejs (actually based on a proposal I made in 2013 in the RactiveJS project), etc.
So, now let's give a simple concrete example, with just 2 classes (the actual application has 20 Entity classes and 60+ request types):
Given two entities:
Now assume a single html table, showing a list of users with these columns:
Company name, User name
So, first the client loads the user table.
The actual users rows may depend on whether the client is an administrator, or a group leader, etc.
Now that table is a projection/lens/reactive-query over a subset of the Company and User entity classes.
Next a request comes in which deletes a company.
So we need to send a message to the relevant clients to remove the rows in their table.
That's the basic scenario.
1. if the transaction fails, then nothing gets sent out.
2. in the real application, figuring out what get sents to whom isn't so straightforward, ie: it can't be done mid-transaction. because most views are composed from several different entity classes, and might depend on whether both (or neither) are mutated. So these projections can only be calculated post commit.
So, based on current thinking, I need to:
1) set the config file to track array changes.
2) capture all entities changed during the transaction.
- most likely this would be a list of both the entity class and it's id
3) then, if the transaction succeeds, immediately follow it with another transaction which calculates new views, based on which entities changed. ie: a single calculation that runs at the end of every request and calculates view changes.
4) That transaction must not alter the database! So, safest to just roll it back.
Any better way to do this?
The way in which I'm doing it now is manually calculating changes specific to each of the 60 request types, which is error-prone, and requires significant testing.
What I'm looking to do is to be able to use dirty tracking to a single 'view projection update' calculation at the end of any request.