Accessing Logfiles
tfeige91 opened this issue · comments
Hi Vanessa,
first thanks for your great work with the Expfactory - it's awesome!
I actually got more than one question:
1)
We serve the tests on a remote server and had the data written as json-files on the server. However we now want to switch to a mysql-database.
The collected data is now stored in folders named with the IDs.
I accessed the expfactory.log and there the usernames are stored that the participants entered. Is there another way of combining the entered username and the datafiles?
Unfortunately I stopped the container and also removed it so the logfile is gone before I saved it.
I'm all new to docker etc. that's why I might get things not quit right but shouldn't the logfiles also be stored in the volume we generate with this command: _docker run -v /tmp/my-experiment/data/:/scif/data _ ?
Or should I - in order to achieve this - create another to volume and map the /scif/logs to it?
- Will the entered Usernames be stored in the mysql-database?
- Is there a way of adding more variables to the expfactory to be entered such as studyID?
Thanks very much for your help!
Hey @tfeige91 thanks for the kind words! I'll do my best to try and answer your questions.
We serve the tests on a remote server and had the data written as json-files on the server. However we now want to switch to a mysql-database. The collected data is now stored in folders named with the IDs. I accessed the expfactory.log and there the usernames are stored that the participants entered. Is there another way of combining the entered username and the datafiles?
expfactory is designed in a way to make it (by default) more consdervative in storing data - the default will just save the exp_id associated with the subject, and the idea is that you would typically keep some lookup with identifiers in a locked office file, or something like that. If you need to add personal information to experiment data, there are a few options:
- have it added as participant data, which then would need to be parsed and added to experiments to save
- design an experiment to ask for demographics that you need
You can see that by default the export (the json in each of those folders) is only going to hold the experiment data, exp_id, and is named by the user token. So to add anything else to the data files you need to do either of the above.
Unfortunately I stopped the container and also removed it so the logfile is gone before I saved it.
I'm all new to docker etc. that's why I might get things not quit right but shouldn't the logfiles also be stored in the volume we generate with this command: _docker run -v /tmp/my-experiment/data/:/scif/data _ ?
Or should I - in order to achieve this - create another to volume and map the /scif/logs to it?
You generally sholuld not rely on logs to get participant data, and in fact it was probably an oversight to print the name the subject enters in the logs. If you want to save data from the postgres/sql database to the host, binding the data is the way to go. That will ensure that if your container is accidentally removed, the data persists.
In summary:
Will the entered Usernames be stored in the mysql-database?
No, not unless you design an experiment to put variables or user-entered fields there, and be very careful about this. It's probably best to contact the security team (or similar) at your institution, and ask about what "best practice" is for collecting PHI. For example, if you have some platform online approved for PHI, you can use it to collect data and then give people an expfactory token to use (associated with the data).
Is there a way of adding more variables to the expfactory to be entered such as studyID?
Yes! See the link above to adding experiment variables.
Hi Vanessa,
thx for your quick reply!
I see the concerns about the demographic data. This is in fact nothing we would do nor are we allowed to do so ;)
We would only use the name field to have the study practitioner enter a unique code for the participants so that we can connect the longitudinal data.
I saw a pull request where the form inputs where modifiet to also accept get requests so we might have a look into this.
Until then I think we'll go with one field in the first experiment of the battery where one has to type in the unique code.
Sounds good!