-
Notifications
You must be signed in to change notification settings - Fork 19
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Ensure uids exist for all nodes in app #615
Conversation
New nodes are no longer given an `id` prop. Edges in the network refer to the primary key (uid).
Eventually, this will be user-configurable. Actions and UI-specific meta continue to use `uid`.
Clarify use of key in CardList, and arbitrary ID key in SessionList.
Drag/drop "meta" is currently set directly from node props; these always represent nodes, so can make use of the PK directly.
@@ -737,212 +742,213 @@ | |||
] | |||
}, | |||
"schoolPupils": { | |||
"nodes_primary_key": "studentId", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should we stick with the camel case convention?
I see that we have chosen to make separate uids the responsibility of the user, but I think it's too opaque. If:
Then the user simply won't see the other node once one is added to the network. |
Good point; that would certainly be unexpected. I thought the primary intent for specifying external PKs was to be able to identify objects that should be treated as equal between different data sets. In which case we do still want to support something like: Perhaps the API for describing this is confusing? Would something like this be better?
|
Also, based on your example, I think I should no longer default to any PK. i.e., we won't automatically assume "uid" is unique. |
I think lines 149-150 should change to
I haven't tried all the scenarios yet. I think probably the If I find anything else I'll comment again. So far it's working well though! |
We could update the panels/comparison function to use an arbitrary property on the node? - That might even mean that PKs aren't needed? |
Translate uid to id attribute in xml
@rebeccamadsen thanks, I pushed those fixes. I agree @wwqrd what is the panels/comparison function? |
PKs are definitely needed, particularly for external data which has a lot of functionality we haven't made yet.
This is reminding me very much of the discussion we had about private vs public properties. At the time (https://github.com/codaco/Network-Canvas/pull/443#issuecomment-381155177) I suggested putting all "private" nc properties inside something like |
Update internal key to _uid
Based on a conversation with @jthrilly I've removed support for defining existing PKs in external data ("separate uids", above), and no longer assume that something labeled When using the development protocol, you'll once again see seemingly-duplicated nodes between NG Closeness and NG Classmates. I've also renamed the internal PK to |
These updates look okay to me. |
RE:
In hindsight I think I may have been making the same point as @rebeccamadsen? |
I created #620 to discuss the idea of |
Resolves #415.
This standardizes the behavior of primary keys for nodes in the app:
"nodes_primary_key"
. See the example ofstudentId
in the dev protocol.uid
prop as an identifier. Nodes always have this property defined internally, regardless of the external data's primary key.Things to test
previousInterview
has existinguid
sschoolPupils
uses the same IDs, but uses a custom PK ("studentId")HIVServices
andvenue_list
do not define any primary keysEdit: this also fixes #605, as UIDs should override anything in additionalAttributes (which cannot be unique).