-
Notifications
You must be signed in to change notification settings - Fork 0
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
Annotate sample application schemas #169
Conversation
Things noticed on review (will update as I go through all the schemas): commento
ghchat
hotcrp
socify
mouthful
|
Thanks @rpaul48 I've responded to your questions & feedback below. commento
ghchat
hotcrp
socify
mouthful
|
I've taken a look at
|
Thanks @artemagvanian! Some comments below:
|
Things look good to me. Thanks @rpaul48 and @artemagvanian for the follow up. I think the way the
TLDR: lets keep I am going to take a deeper look. Thanks everyone for you help. |
Apologies for taking a while to get to this, had two comments about ghchat and hotcrp: ghchat I think the addition of the group_info(id) column makes sense, but I think some of the foreign keys need to be changed to reflect the new column:
hotcrp This is less specific to the annotation, but more of a general question for if/how K9DB handles a type of pattern. From what I understand from how HotCRP works, the PaperConflict table encodes different relationships between contactInfo and paperId based on the value of conflictType (e.g. a value for co-author, another value for institutional relationship, etc.). I think depending on the relationship, the data ownership/accessorship pattern might be different, like we would want to extract all papers that a contactInfo has co-authored, but not papers that they might have an institutional conflict with. I think it make more sense if we remove the OWNED_BY annotation on the column in the meanwhile (to prevent returning too many results)? |
Thank you @arjeyaraj!
|
FOREIGN KEY (requestedBy) ACCESSED_BY ContactInfo(contactId), | ||
-- author should see review, but not who reviewed it | ||
-- only thing author should see is content of review, and when submitted (dates) | ||
ON GET contact_id ANON (review_token, reviewType, reviewRound, requestedBy, reviewNotified) |
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.
This does not look right to me.
- There is no contact_id column.
- The contact_id is the reviewer right? We should be anonymizing for the authors of the paper.
Maybe you meant ON GET paperId ANON (....)
? As in, if the authors of the paper request their data, do not show them private info about the review? (Also please make sure to anonymize the identity of the reviewer and who requested the review etc).
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.
You're right, that should be paperId
not contact_id
. Fixed in recent commit.
Just took a look at the other schemas, here are more comments: commento
ghchat
socify
hotcrp
|
Thanks @artemagvanian and @KinanBab ! commento
ghchat
socify
hotcrp
|
For Hotcrp:
|
Some general followups:
Both these things will be done and merged either Tuesday or Wednesday. My plan is to merge this immediately after. @benkilimnik It would be great if you can do the following after the above is done and merged:
I will ping you on slack when the above is done and merged so that you can do the final touches. I can merge this immediately after. |
Sorry @benkilimnik I meant |
* Modify sqlengine/create.cc to correctly handle ACCESSED_BY self references * Throw an error if self reference is OWNED_BY, OWNS, or ACCESSES * Add tests to ensure self reference works correctly, including anonymization * Fix visual bug in EXPLAIN COMPLIANCE * Decrement user count in gdpr_forget.cc
9456d27
to
3fb00c1
Compare
* Commento * ghchat * hotcrp * instagram * schnack * socify * mouthful This includes adding missing FKs for many of the schemas that did not have any FKs, extracting schema from non-sql code, and normalizing some schemas that were not in normal form. Add a README with a description of interesting scenarios and output of EXPLAIN COMPLIANCE.
1abd09e
to
c83dd78
Compare
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.
All good! Approved
Adds data ownership annotations to the schemas of a number of sample applications and modifies them for compatibility with
k9db
. Unit tests may be added for them in the future.Progress:
Large schemas deprioritized, moved to branch
annotate-prestashop-opencart