Major refactoring on Room DB classes

[sshann]

I merged all issues related to the database to this issue to have a single point of discussion. Since some changes overlap and there are changes in several aspects of the database, it makes sense to centralize these.

Classes architecure

There is currently 2 architecture being used for the Room classes:

• Domain-based (e.g., grouping all classes related to visiting time together)
• Function-based (e.g., splitting classes per DAO, entity, converter, etc.)

Initially, there was only the function-based architecture.
When I picked up the project, this architecture was not 100% followed, as there were DAO and Entity classes together in the root of the Room package. They are still there actually,

When I had to record additional data I tested using a domain-based organization.
So I am partially guilty of the current disorder.
After working on Nappa for the past weeks, I do feel like this pattern (domain-based) is better to work on, so I favour it.
However, I don't have the time to completely organize the database.
Sadly, I will need to leave this task for future contributors or when I have the time in the distant future.

Class names

• Renaming the Entity classes from MyEntityData to simply MyEntity --> less verbose
• With the addition of ActivityVisitTime, the entity SessionData could be renamed to ActivityVisitFrequency or simply VisitFrequency (in the case of the later, also rename the visit time entity)

Enforcing rules in the database level

• Enforcing required data by either making entities attributes type primitive or annotating object types with @nonnull;
• Enforcing foreign keys
  • Currently only enforced in the application levels, which allows adding invalid FK

Moving classes

• Extracting model class UrlCandidateToUrlParameter from UrlCandidateDao;
• Extracting model class SessionAggregate from SessionDao;
• Extracting LAR operations from ActivityTableDao
  • LAR refers to PageRank, HITS and Salsa scores, but I am not sure what the acronym means;
• Moving the class ParameteredUrl to Room.
  • This class is returned as a model in select operations in the DAO class UrlCandidateDao.

Database Views

• Using DatabaseView to simplify some queries;

Warnings

• Resolve warnings listed when building the library:

> Task :android_prefetching_lib:compileDebugJavaWithJavac
/home/sshann/Documents/thesis/NAPPA/Prefetching-Library/android_prefetching_lib/src/main/java/nl/vu/cs/s2group/room/dao/UrlCandidateDao.java:37: warning:  nl.vu.cs.s2group.room.dao.UrlCandidateDao.UrlCandidateToUrlParameter has some fields [idActivity] which are not returned by the query. If they are not supposed to be read from the result, you can mark them with @Ignore annotation. You can suppress this warning by annotating the method with @SuppressWarnings(RoomWarnings.CURSOR_MISMATCH). Columns returned by the query: id, count, urlOrder, type, urlPiece. Fields in nl.vu.cs.s2group.room.dao.UrlCandidateDao.UrlCandidateToUrlParameter: id, idActivity, count, urlOrder, type, urlPiece.
    List<UrlCandidateToUrlParameter> getCandidatePartsListForActivity(Long idAct);
                                     ^
/home/sshann/Documents/thesis/NAPPA/Prefetching-Library/android_prefetching_lib/src/main/java/nl/vu/cs/s2group/room/PrefetchingDatabase.java:24: warning: Schema export directory is not provided to the annotation processor so we cannot export the schema. You can either provide `room.schemaLocation` annotation processor argument OR set exportSchema to false.
public abstract class PrefetchingDatabase extends RoomDatabase {
                ^
Note: /home/sshann/Documents/thesis/NAPPA/Prefetching-Library/android_prefetching_lib/src/main/java/nl/vu/cs/s2group/PrefetchingLib.java uses or overrides a deprecated API.

Possible bugs?

• I observed that there are records in the entity RequestData with the property id_activity containing Null value. Is this the expected behaviour (e.g., requests that were not prefetched) or is this actually a bug? These records are never used in Nappa.