Confusing that participant.id is a token in the filesystem, but numeric in sqlite

[earcanal]

Moving out of #41.

@vsoch "Yeah I thought so too, but how would you suggest fixing? If the participant id is a changing token in relational databases, that means that we query / lookup based on token, but when a new token is issued (and the old one overwritten) the experiments admin would need to keep track of that. Is your preference to completely ignore the database id and just use tokens (that change?)"

[vsoch]

It comes down to database indexing. The database is going to add an id and auto-increment each time. For a filesystem run, it would be akin to adding another auto-incrementing folder:

/scif/data/expfactory/0000/xxxx-xxxx-xxxx
/scif/data/expfactory/0001/xxxx-xxxx-xxxx

but it's not really necessary, and adds another level of ids / detail that we don't care about. Which is why we just have the uuid's to replace.

Now, for the sqlite / postgres (and other relational) we could resolve this by completely hiding the ids from the administrator, and having them looked up based on token. I didn't do this because in this case, I think that it doesn't hurt to have them. They would be exported with the data and something else that might be useful.

[earcanal]

I wouldn't let this hold up #41, but leave it open as a potential implementation if uuids make people cry. My fear is that people will prefer to use pid=[1..n] in their studies and will hate having to do the token->pid mapping themselves (in a spreadsheet presumably).

[vsoch]

oh I see, so you would maintain the simple ids, and then have the tokens change up, and the fix for that would be to add a level to file system saving that can represent the simple ids (and then still the tokens). +1 that let's keep this open, and likely address in the future, but not for this PR (because it's yuuge!)

[earcanal]

I almost understand/agree with that! TBC ...

[vsoch]

I think the tokens are uuids so they should consistently be strings now?