initialization.md

Initialization

This section explains how to handle data storage.

We handle data storage according to the following process :

The folder /src/db contains all the JSON entities that are directly stored in the CouchDB during the initialization process that is executed in the splash screen. They are stored under their related doctype.

Initialization and Updating

During the initialization process, we store a hash for each dataEntity that is likely to be changed or updated. The hash is stored in the userProfile.

[
  {
    "ecogestureHash": "",
    "challengeHash": "",
    "quizHash": "",
    "explorationHash": "",
    "duelHash": "",
    "isFirstConnection": true,
    "haveSeenFavoriteModal": false,
    "haveSeenOldFluidModal": false,
    "haveSeenLastReport": true,
    "sendReportNotification": false,
    "monthlyReportDate": "0000-01-01T00:00:00.000Z"
  }
]

This way, once the initialization is launched, we compare the hash we have in the current userProfile with the one generated from the entity located in /db folder, and if they are different we update the CouchDB with the new data.

In order to handle this process, each entity that is likely to change has a function that takes the current hash in entry, and execute the following process :

• creates a hash from the related entity file (for example EcogestureData.json)
• get the entities from the database
• if there is no entity stored, populates the related doctype (for this example ECOGESTURE_DOCTYPE) for each item stored in the entity file
• compare the number of entries created in the doctype with the number of item in the entity file
• if the previous hash and the new hash are different, delete all entries in the doctype and populates with the items stored in the entity file

Functions used to init or update the hash :

Function
initEcogesture(hash: string)
initChallengeEntity(hash: string)
initDuelEntity(hash: string)
initQuizEntity(hash: string)
initExplorationEntity(hash: string)

:::info Exception for ecogestures

When we update the ecogesture list in ecogestureData.json, we also get the previous existing list to transfer the ecogesture status (doing and/or objective) to the updated list.

:::

dataEntity vs userData

In the project, you'll see two versions for the same data. The dataEntity (quizEntity, challengeEntity, ...) is the data stored in the db folder and in the CouchDB. These data are only edited in the CouchDB when we update a challenge/quiz/duel or add a new one.

The userData (userChallenge, userQuiz...) is created from the entity and extended with user's data, such as his progress, his consumption data, goals, fails etc.

Using this 2 structures allows us to keep user's data when we'll update the application, by editing just the entities.

Relationships

Relationships is a functionality made by cozy, they are built with the name of the relation, containing a "data" object, itself containing the id of the related item and its doctype "_type". Using this allows us to reduce the size of the stored items and increase readability.

Relations are set as HasOne relationships for Quiz and Duel because there is only one quiz and one duel for Challenge. Thus, we use a HasMany relation for the Exploration, because one challenge can have several exploration in order the handle the specific cases of fluid-based explorations.

You can see more about relationships on cozy documentation.

"relationships": {
      "quiz": {
        "data": { "_id": "QUIZ001", "_type": "com.grandlyon.ecolyo.quiz" }
      },
      "duel": {
        "data": { "_id": "DUEL001", "_type": "com.grandlyon.ecolyo.duel" }
      },
      "exploration": {
        "data": [
          {
            "_id": "EXPLORATION001",
            "_type": "com.grandlyon.ecolyo.exploration"
          }
        ]
      }
    }

UserData creation

We create a userData and store it in the CouchDB under the doctype userData name 'com.grandlyon.ecolyo.userDataName'. During this process, the objects related to the dataEntity will be be converted to an user version which contains information about the user(example: user progress, the fluids connected and so on).

To illustrate this, let's show an example of the conversion of duelEntity to UserDuel :

DuelEntity {
  id: string
  title: string
  description: string
  duration: Duration
}

Becomes :

UserDuel {
  id: string
  title: string
  description: string
  duration: Duration
  threshold: number
  state: UserDuelState
  startDate: DateTime | null
  fluidTypes: FluidType[]
  userConsumption: number
}