Home

Welcome to the Book Voyage wiki!

Since the project is still small, all information is currently placed on this page.

Assignment Algorithm

This section explains how the platform works in the back-end. What is the anatomy of a book journey?

Preparation

Owners (users) are entered into the database beforehand (with email and name), together with a book owning containing the destination the owner specified. An owner can have multiple book ownings: multiple books at different locations.

book instances are also entered. Their prime attribute is a book code. These need to be generated, printed and put into physical books. These codes are secret and act as passwords to the books and should therefore only be known by those who have a physical copy in their hands. Publicly, books are identified with a number. Books are then distributed in batches at social events.

Once books are distributed

Those who receive a book are asked to enter a code on the platform. This is the first step of the process. When entering it, there are four possible scenarios:

1. The corresponding book instance is not assigned and a book owning is available. The two are tied and the owner is notified by email that their journey is on its way. They receive a password reset link to create an account.
2. The corresponding book instance is already assigned - a previous holder registered it already.
3. The corresponding book instance is not assigned and no book owning is available. No linking can occur, and later on the user is notified that the book has no end destination (yet): they are free to take it to interesting places.
4. There is no corresponding book instance. An error is shown.

After entering the code in scenarios 1-3, the holder creates a user account. They then create a book holding, containing a location and a message. During this process they are also asked to set up some preferences (whether they want to be anonymous and whether they would like to receive updates by mail).

Once registered, the application goes to the journey page, which is publicly shareable and contains one book with all previous holders and the owner. Upon submitting, an email is sent to all previous holders and the owner who indicated they wanted to receive such updates. The holder then passes down the book, and the process repeats (through scenario 2). At the moment, the same user can register the same book multiple times - extending the list of holdings. This is as intended and will be evaluated.

Models/Database Implementation

You can access the source of this picture at QuickDBS, using the following code:

# Modify the code to update the DB schema diagram.
# To reset the sample schema, replace everything with
# two dots ('..' - without quotes).

Book
-
id PK id
title CharField(64)
authors id FK >-< Author.id
abstract CharField(512)
cover ImageField

Author
-
id PK id
first_name CharField
last_name CharField
date_of_birth DateField
bio TextField

BookInstance
-
id PK id
access_code CharField(64) IDENTITY
book id FK >- Book.id
#finalLat DecimalField # can be empty
#finalLon DecimalField # can be empty
batch id FK >- BookBatch.id
arrived boolean

BookOwning
-
id PK id
owner ForeignKey FK >- User.id
book_instance ForeignKey FK >- BookInstance.id
time DateField
message CharField(512)
location PointField()

BookBatch
-
id PK id
event CharField(64)
country CharField(64)
location Point()
date DateField

BookHolding
-
id PK id
holder ForeignKey FK >- User.id
book_instance ForeignKey FK >- BookInstance.id
#lat DecimalField
#lon DecimalField
time DateField
message CharField(512)
location PointField()

User # Django class
-
DJANGO CLASS
id PK id
username string
first_name string
last_name string
password string
email string

GROUPS # Django class
-
notifications boolean
anonymous boolean



[settings]
Position 155 35
Zoom 100
DefaultFieldType int
CaseSensitive on

[layout]
Book 193 134

BookInstance 447 171

User 808 281
Author -68 150
BookHolding 455 387
BookBatch -55 411
GROUPS 967 406
BookOwning 790 51