TravelTransactionLog changes

Av Marek Vokáč, Oppdatert på 21. feb. 2023
push_pin
star

The TravelTransactionLog ("TTL") table dates back to the deep past of SuperOffice, when the Internet was a nice idea and crappy/expensive hotel phone lines were the reality. Being able to take the database with you was a real power feature. Even better, you took only a subset that was relevant to you, saving expensive megabytes on your little harddisk.

NetServer still notes changes in TTL, and it's still valuable as a record of changes being made - at least to tables that were part of the Travel system. Most of this logging is relatively cheap and worth keeping. However, there are several special events that complicate the code and have some performance overhead.

These are the changes that would, in the old days, have influenced the filters used to define the subset of the database that users would take with them: changes to contact.associate_id (and a few obscure tables only used for the Area Management configuration in Travel). The other category is logging of per-field changes on Udef tables. Both of these can result in additional database traffic (because we need to know the previous value), and we can't write the actual change until that information has been secured.

In the TTL table, these events have event ID's higher than 4864. The basic events for Insert (4352, 0x1100), Update (4608, 0x1200) and Delete (4864, 0x1300) will be kept; but we want to stop logging all other events.

If you have no idea what I'm writing about here - fine! No problem!   But if this causes cold sweat and incipient panic then I need to know.

Cheers,

Marek

 

Hi Marek, besides the create/update/delete we depend on the UpdateOwner = 5120 to handle appointment owner changes properly. I'm not sure what the impact would be if that's gone, planning wise we cannot change this on short term, so what's the planning for this?
Carlo Pompen 25. apr. 2023
Ooops, this was a very useful comment. Ownerchanged is one of the events I would like to avoid, because it requires us to compare the current vs. new value (and we might have to hit the database to determine the current value).
Don't worry, comment noted and we won't take it away without more discussion.
Marek Vokáč 26. apr. 2023
Thanks, I will place this in our backlog to investigate at some point. We do not store any customer's data for obvious reasons (also not the owning associate at the moment of syncing), so this could mean we have to do an additional query every time, instead of you, though I can imagine the benefit on your end is higher.
Carlo Pompen 26. apr. 2023
Depending on how the update happens within Netserver, we often have the previous value already in memory. If so, we don't need to look it up again. SuperOffice is not an application that insists on real-time consistency and if someone else has changed the same record in the (few) milliseoncds between retrieval and update, then, well... we don't see that. So the cost may be low; it was more a case of trying to reduce the codebase a bit.
Marek Vokáč 26. apr. 2023
Yes, the basic events for udef tables will stay (and they will continue to include the udef definition version in the prev_record_id, in case anyone is interested).
Marek Vokáč 22. feb. 2023
I checked our primary application that (still) uses the traveltransaction log, we primarily trigger on insert/update/delete, so no issue there. I do assume a update ttl record is still create for the ud* table when user defined field is changed?
David Hollegien 22. feb. 2023