Add log items

[benloh]

@jdanish This should give you a sense of where and how the logging works. Feel free to edit the messages as you see fit. You can do a full search on UNISYS.Log to find all the current UI-facing events. In addition, there are server backend logs that you can find via WriteRLog

[jdanish]

Awesome. Are node update and save redundant? At a glance I didn't see a major difference?

[jdanish]

Oh sorry, and "edit" doesn't display the node details, so right now the only way to see what was edited is to see if it was previously edited. However if "edit" shows what it is before the edit, and then save / update shows after, the comparison is easy and all close (ish) in the log file?

[benloh]

update is a db log item. save is the UI event. We can remove one or the other if it feels too redundant.

"edit" doesn't display the node details No problem. I can bundle that up with the initial call.

[jdanish]

I don't see why I'd look for save and update since the only reason there'd be one and not the other is an error, right? Sorry if I am missing something. In which case I'd say let's not have both and keep the files smaller.

Updated: update is more backwards compatible while save is more reader friendly ... so I'd lean toward update, but don't have a strong feeling.

[benloh]

I don't see why I'd look for save and update since the only reason there'd be one and not the other is an error, right? Sorry if I am missing something. In which case I'd say let's not have both and keep the files smaller.

Yeah, that's basically right.

Updated: update is more backwards compatible while save is more reader friendly ... so I'd lean toward update, but don't have a strong feeling.

We've been trying to standardize on language, and "updated" is the perferred term for database operations, so we'll stick with that and remove "save".

[benloh]

@jdanish Note that currently the db call log items (like "update") do not include the node/edge labels, while the "edit" calls do include the node/edge labels.

Edge labels do not really exist on the db side (since edges do not actually have lablels, but just use the source node label and target node labels) and are constructed on the fly just for the log.

To facilitate a standard output, should we remove the label since the relevant info is included in the JSON dump? (Having the label does help make the log easier to read, but then you'll have a column alignment problem if you're trying to spit out csv).

e.g.

2024/05/15  21:34:14    focus   UADDR_01    FOCUS-B-LPJ edit node   1   Tacitus {"id":1,"label":"Tacitus","provenance":"Added by FOCUS-B-LPJ on 4/15/2024, 3:50:12 PM"}
2024/05/15  21:34:16    focus   UADDR_01    FOCUS-B-LPJ update node 1   {"id":1,"label":"Tacitus","provenance":"Added by FOCUS-B-LPJ on 4/15/2024, 3:50:12 PM"}

2024/05/15  21:35:55    focus   UADDR_01    FOCUS-B-LPJ edit edge   2   Tacitus➔Hermione    {"id":2,"source":1,"target":2,"provenance":"Added by FOCUS-B-LPJ on 4/18/2024, 3:53:41 PM","type":"Likes","weight":1}
2024/05/15  21:36:24    focus   UADDR_01    FOCUS-B-LPJ update edge 2   {"id":2,"source":1,"target":2,"provenance":"Added by FOCUS-B-LPJ on 4/18/2024, 3:53:41 PM","type":"Doesn't Like","notes":"abc","info":0,"weight":0,"comments":"asdf","citation":"asdf"}

[jdanish]

I do prefer consistency and CSV opening is a key goal for analysis purposes. In the case of the node it's an easy decision because the label is in the json dump. In the case of the edge, my worry is that you can't reproduce the node names at that moment in time unless they were touched recently, right? so, in the case of:

Create Tacitus and Hermione ... 3 days pass Edit Tacitus -> Hermione ... (edge 1) 2 hours later, change Tacitus to Harry, because what was going on

3 months later, analyze log ... it's not clear what the nodes were called when edge 1 was edited

Would it be a big deal to stuff an "edge_label" into the json before printing it? It can be removed or ignored after? Or source_label and target_label?

[benloh]

@jdanish Alright, I'm glad I raised the issue. I figured that would help.

The challenge is that the current edge update edge log is deep in the guts of the server-side server-database calls, where the source and target info are stored as node ids and dereferencing and reconstructing the edge label adds a layer of inefficiency and indirection. I think the most efficient solution is to support the log on the client side. So you'll have to live with an extra "save edge" call. We can call it ui click save or something like that to make it clearer. So you guys should probably just ignore the extra call. Or perhaps for better parity, we re-add the node side as well. So both nodes and edges will get a "ui click save xxx" and "updated xxx" log item.

[jdanish]

OK, makes sense. I like that - so "click save ... node name" or "click save ... edge name" will help us know what we are talking about, and then update is there for consistency and so we know it hit the server, though we can do most of our work from click. OK!

[benloh]

@jdanish I think this should work now. You might want to generate some long logs and import it into Excel to make sure you have what you need.

[jdanish]

Seems pretty good to me. One note is that the arrows import into excel as ûî but they are rendered correctly in the log file. So we can handle that on import (just noting it).

The one piece that feels not 100% intuitive is the toggle on tabs - is it possible to change that to be open / close or toggle open, toggle close? Otherwise it requires knowing the history. If it's a huge deal, no worries. Otherwise this looks right and I'm ready to merge / accept.

[benloh]

Seems pretty good to me. One note is that the arrows import into excel as ûî but they are rendered correctly in the log file. So we can handle that on import (just noting it).

We can change it to use a dash + greater than sign: -> if we want to avoid unicode problems.

The one piece that feels not 100% intuitive is the toggle on tabs - is it possible to change that to be open / close or toggle open, toggle close? Otherwise it requires knowing the history. If it's a huge deal, no worries. Otherwise this looks right and I'm ready to merge / accept.

Yeah, I know it wasn't ideal. I was trying to avoid having to completely redo the toggle. It's not a huge deal. It can use a refactor anyway.

[benloh]

@jdanish better?

2024/05/17  15:32:36    focus   UADDR_15    FOCUS-B-LPJ select tab Nodes Table
2024/05/17  15:32:37    focus   UADDR_15    FOCUS-B-LPJ select tab Edges Table
2024/05/17  15:32:37    focus   UADDR_15    FOCUS-B-LPJ select tab Help
2024/05/17  15:32:38    focus   UADDR_15    FOCUS-B-LPJ deselect tab Help, reverting to Graph
2024/05/17  15:32:38    focus   UADDR_15    FOCUS-B-LPJ select tab Edges Table
2024/05/17  15:32:39    focus   UADDR_15    FOCUS-B-LPJ deselect tab Edges Table, reverting to Graph
2024/05/17  15:32:40    focus   UADDR_15    FOCUS-B-LPJ select tab Nodes Table
2024/05/17  15:32:40    focus   UADDR_15    FOCUS-B-LPJ deselect tab Nodes Table, reverting to Graph
2024/05/17  15:32:41    focus   UADDR_15    FOCUS-B-LPJ deselect tab Graph, reverting to Graph
2024/05/17  15:32:42    focus   UADDR_15    FOCUS-B-LPJ deselect tab Graph, reverting to Graph
2024/05/17  15:32:43    focus   UADDR_15    FOCUS-B-LPJ select tab Nodes Table
2024/05/17  15:32:44    focus   UADDR_15    FOCUS-B-LPJ deselect tab Nodes Table, reverting to Graph
2024/05/17  15:32:44    focus   UADDR_15    FOCUS-B-LPJ select tab Nodes Table
2024/05/17  15:32:45    focus   UADDR_15    FOCUS-B-LPJ deselect tab Nodes Table, reverting to Graph
2024/05/17  15:32:45    focus   UADDR_15    FOCUS-B-LPJ select tab Nodes Table
2024/05/17  15:32:46    focus   UADDR_15    FOCUS-B-LPJ deselect tab Nodes Table, reverting to Graph
2024/05/17  15:32:46    focus   UADDR_15    FOCUS-B-LPJ select tab Nodes Table
2024/05/17  15:32:47    focus   UADDR_15    FOCUS-B-LPJ deselect tab Nodes Table, reverting to Graph

The "Help" tab was renamed to "More" sometime in the past. I left the GA tag calling it "Help" just in case you needed to match the historical record.

[jdanish]

Yes this looks good. Thanks!