You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Right now we store the text of the messages/files as files on disk. The proposal here is to store message and reply content in the local sqlite database instead of a file on disk.
Advantages
The main advantage is cleaner separation of data handling and GUI logic: this change enables us to move more data-layer functionality into methods on the database models (out of data.py and out of storage.py into one place: the database models). The issue with not doing this is that we then either have to use a clever solution like what is described in #197 or we have to pass around the data_dir attribute into parts of the gui code (#212) so that we can then pass the data_dir to another function (in storage.py used for fetching the content in a file).
This means that functionality like last_activity_summary_text gets implemented as a method on the Source class. We get the content via item.content elsewhere in the code (clean/simple). The gui parts of the code don't need to know what data_dir is.
(This also is a step in the right direction if we ever want to enable people to search through text in the client application)
Disadvantages
Larger database, but at the scale of SecureDrop this should not be a problem (i.e. with ~100 sources the database should be only a few MB or tens of MB).
The text was updated successfully, but these errors were encountered:
One clarifying question: When you say "files" above, do you also mean non-message submissions such as PDFs or whatnot? I assume not because that would probably break sqlite 😅
I do agree that this is probably a better way to do this. This would likely need a boolean column to know whether the reply is fully decrypted.
One clarifying question: When you say "files" above, do you also mean non-message submissions such as PDFs or whatnot? I assume not because that would probably break sqlite 😅
Part of #231.
Right now we store the text of the messages/files as files on disk. The proposal here is to store message and reply content in the local sqlite database instead of a file on disk.
Advantages
The main advantage is cleaner separation of data handling and GUI logic: this change enables us to move more data-layer functionality into methods on the database models (out of data.py and out of storage.py into one place: the database models). The issue with not doing this is that we then either have to use a clever solution like what is described in #197 or we have to pass around the
data_dir
attribute into parts of the gui code (#212) so that we can then pass thedata_dir
to another function (instorage.py
used for fetching the content in a file).This means that functionality like
last_activity_summary_text
gets implemented as a method on theSource
class. We get the content viaitem.content
elsewhere in the code (clean/simple). The gui parts of the code don't need to know whatdata_dir
is.(This also is a step in the right direction if we ever want to enable people to search through text in the client application)
Disadvantages
Larger database, but at the scale of SecureDrop this should not be a problem (i.e. with ~100 sources the database should be only a few MB or tens of MB).
The text was updated successfully, but these errors were encountered: