Yes, we can still rely on those values but with a little more hybrid approach, every step remain same instead of this :
- we cannot rely on the database to get active note resource data (as it might not be 5min yet), though we can just read the note content to get the resourceId instead, using this function in
Note.ts:
I don’t quite understand what you’re saying. Are you suggesting that when making a change to an encrypted note, you will add the resources to note_resource table? That wouldn’t work, because if you then sync the note to another client, the note_resources table on that client will not have recognition of the included resources, and never will unless you modify the note on that client
I don't think we need any extra peice of code here because the decryption of note is already done in the core Resource.ts, the revision service will eventually use this core to decrypt the data.
Your solution has to be completely rock solid to not allow any way for an encrypted resource to be in an unencrypted note, otherwise the resource will be inaccessible in notes and revisions where this is the case, without any password prompt implemented for the scenario
Regarding this point, I don't think they are actually orphaned
Ok they are not orphans, but its not ideal to be making duplicates which don’t get reverted if you later decrypt them