This demo uses the LDES client and replicates the GIPOD mobility hindrance LDES to a MongoDB database.
The database can be initialised by running the docker-compose.yml
file with the following command:
> docker-compose up
The docker-compose file will start two containers → mongo
and mongo-express
. The first container mongo
contains a MongoDB database. The latter container provides a Web-based admin interface that can be used to interact with the MongoDB database.
The init script will create a new database called ldes
with two collections in it:
ldes_entity_timestamp
→ contains the entity URIs along with the timestamp of the most recent versionldes_data
→ contains the mobility hindrances
It is possible that upon the first run, the mongo-express
container fails to run. This is because mongo-express
tries to connect to the MongoDB database in the mongo
container, and it is not fully initialized yet.
When this issue occurs, just restart the mongo-express
container:
> docker start mongo-express
First, install the necessary packages with the following command:
> npm install
The code is written in Typescript and must be compiled to Javascript in order to execute it:
> npm run build
When the code is compiled to Javascript, navigate to the bin
folder and execute the following command:
> node --max-old-space-size=8192 runner.js
The script will create a database and LDES client. If the LDES client has had a previous run, the previous state will be imported into the current LDES client, so that it does not start iterating the LDES from the beginning, but from the point where it previously stopped.
For this demo, we simulate that we only want the latest version of every object.
For every member we receive from the LDES client, we execute the handleMember
function.
In the handleMember
function, we check if the mobility hindrance has a consequence in which we are interested. The list of consequences that are used to filter can be found in the Mongo class.
For every entity that is added to the database, we store the timestamp of its latest version in the ldes_entity_timestamp
collection. So, for every version of an entity that we receive, we query the timestamp collection to check if the timestamp of the received version is more recent than the one already in the database. If that is the case, the means the version that we received is more recent than the one in the database. So, then we update the ldes_data
collection with the newest version for the entity, and we also update to ldes_entity_timestamp
collection with the timestamp of the newest version.
As timestamp, we use the createdOn
field of a mobility hindrance, as this indicates at which time the 'event' occurred.