Changing General Node Architecture

[abrobbins90]

The current Node class (client side) needs to be expanded to support more functionality

[abrobbins90]

Proposed updates to Node superclass, in dictionary format:

{
     id: _persistent node id_,
     type: _node type_,
     dispName: _node display name _,
     names: _array of alias names for node_,
     edges: [_array of edge ids_],
     info:  {
          version: _node version number_,
          creation_date: _date node was created_,
          last_modified: _last date node modified_
     }
}

[MareoRaft]

looks good to me. i have some minor points:

• id -> _id because that's what MongoDB wants
• dispName -> displayName for readability
• names -> nameAliases or aliases aliases is a standard term for this sort of thing, and i think this fits the bill. Of course we can display a more user-friendly term to the users in the GUI itself.
• creation_date -> creationDate It seems that auto-generated MongoDB _id's contain creation date info in them (reference). But if we are generating our own id's (we are), then i don't think we can retrieve the info dynamically, so it makes sense to have this.
• last_modified -> lastModifiedDate also good. i saw here that some people keep track of entire audit trails. maybe there already exists a library out there for this. but i have no preference.

I'm sortof wondering why some things are grouped under "info" while others are not. Could we just make everything top-level? Is there an advantage or disadvantage to either of these approaches?

[MareoRaft]

Also, what is the purpose of the version number? Do we intend to store more than one version of the node in the DB? Like a history thing so that people can "go back in time" / "undo" if they deleted granny's favorite recipe?

[MareoRaft]

So the next question is can we use the lastModifiedDate(s) (or maybe modificationDate(s) is a better name) to do whatever we needed the version number for? It's like a version number, but even better because it tells you exactly when that version was made.

[abrobbins90]

Agree with all the variable names.

For the version number, I was considering this to be for the code, not the node's own version. So if we ever change something about the node structure, we can easily search out for outdated nodes. This is very much something that I don't necessarily anticipate needing, but it seems to easy to add, so why not. It could always be useful down the line. And for the info property, maybe it's a branding issue. It's more like metaData. It contains info about the node that is not relevant to its actual operation. I also just like having some kind of catch-all field for miscellaneous info too.

It might be nice to store some kind of record. I have been bouncing all sorts of ideas about this back and forth. Certainly, on the client side, I think we can do some saving and backups when someone is editing a recipe. Basically keep some snapshots available that the user can undo if necessary in the short term. And then on the really long term, I think keeping backups periodically is good. Given that many recipes are not changing every other day, that would likely suffice for most purposes. If we want to do an audit trail, I think we could consider that in the future. Sounds harder...

[MareoRaft]

I'm ok with you moving forward with this stuff. Some sort of "backups" or "history" is a good idea, but I think it's out of the scope of this specific ticket. We would need to put a lot of thought into that.