|
|
|
|
# Store
|
|
|
|
|
|
|
|
|
|
The Store is the central point of the application. It is responsible for
|
|
|
|
|
keeping all the information sent by Capturers and providing a search/list
|
|
|
|
|
functionality for Viewers.
|
|
|
|
|
|
|
|
|
|
We would probably need a design like:
|
|
|
|
|
|
|
|
|
|
## Entry
|
|
|
|
|
|
|
|
|
|
| Field | Description |
|
|
|
|
|
| ------- | --------------------------------------------------- |
|
|
|
|
|
| id | UUID of the record. |
|
|
|
|
|
| title | String, produced by a Capturer. |
|
|
|
|
|
| content | Text, produced by a Capturer. It's always Markdown. |
|
|
|
|
|
| source | Capturer name. |
|
|
|
|
|
|
|
|
|
|
## Meta
|
|
|
|
|
|
|
|
|
|
Meta contains the meta information of the entry, used by a Capturer. A view may
|
|
|
|
|
or may not display those fields.
|
|
|
|
|
|
|
|
|
|
| Field | Description |
|
|
|
|
|
| ------- | --------------------------------------------------- |
|
|
|
|
|
| id | UUID of the record. |
|
|
|
|
|
| entry | ForeignKey of the entry. |
|
|
|
|
|
| name | Meta field name. |
|
|
|
|
|
| value | Meta field value. |
|
|
|
|
|
|
|
|
|
|
## Attachments
|
|
|
|
|
|
|
|
|
|
Attachments are not meta information, but something related to the entry -- for
|
|
|
|
|
example, if the content contains any images, those are added as attachments.
|
|
|
|
|
|
|
|
|
|
| Field | Description |
|
|
|
|
|
| ------------ | --------------------------------------------------- |
|
|
|
|
|
| id | UUID of the record. |
|
|
|
|
|
| entry | ForeignKey of the entry. |
|
|
|
|
|
| content_type | Type of the content. |
|
|
|
|
|
| content | Attachment content, in Base64. |
|
