This repository has been archived by the owner on Jul 18, 2022. It is now read-only.
-
Notifications
You must be signed in to change notification settings - Fork 1
Proposed Data Model
rcking edited this page Dec 22, 2011
·
8 revisions
How to design the Download Model entity?
- A Download belongs to a User
- A Download includes information about the data DatasourceProfile
- A Download has a unique path on the Storage
- HOWEVER, a Download must be self-contained (i.e. not just reference a DatasourceProfile or Workflow Model entity, since these might be removed by the user).
Some thoughts on the relation between the Download Model entity and the DownloadSource/DownloadSink (we need a good & descriptive name for this/these class(es)!)
- Should source/sink be implemented in a single class?
- Where/when is the actual Download Model entity created? -> Must happen in the DownloadSink's upload method
- The DownloadSink's upload method returns the path on the Storage as return value (it can't return the Download itself, otherwise we're breaking the uniform interface required for the Workflow)
- The DownloadSource's download method feels kind of recursive now (just delegates to the storage?). Might not be an issue, but maybe it makes sense to redefine the Storage interface slightly?
- email address is the primary key
- username, password for login
- passphrase in order to access encryption keys
- encryption keys (1:n)
- physical address for receiving media by post
- billing information, credit card for premium users
- configured sources and syncs (1:n)
- downloads (1:n)
- workflows (1:n)
- preferences?