How to handle the waiting queue for experiments

[JannisBush]

At the moment, if user 1 is doing chain X realization Y of an experiment and user 2 is waiting for him to finish (chain X realization Y+1) and user 1 is quitting, user 2 still waits for chain X realization Y to finish, i.e. a new user 3 to finish chain X realization Y.
It might be better to "downgrade" user 2 in this case and let him do realization Y instead of waiting for a new user to do it.

[x-ji]

Yeah I also thought about that, but it would introduce some extra complications to implement. If participants join the experiments relatively quickly it might not be a big issue to just get the next participant take the place of the first participant who left. Guess Michael would have some comment on it as he has more experience with how experiments usually proceed.

[x-ji]

Or maybe you could try an implementation. It could be a chance for you to get familiar with the backend code. Though don't worry if you don't have time for it currently.

[JannisBush]

I might give it a try after I have looked at the phoenix framework, at the moment I am still looking at pure elixir. Also there are some other things with higher priority for the moment.

What is the best/easiest way of developing/testing new BABE versions? I thought about the new local one-click deployment, but the current babe_db.sqlite3-file is incompatible with your new changes and I am not sure how to change it. Always push my changes to an own heroku instance? Or even run a "full" sever?

[x-ji]

Good call. I need to write a new migration file for SQLite and produce a new babe_db.sqlite3 file. SQLite doesn't support dropping columns in migrations, so in each major new version a clean slate would be the best way to start. I'll upload it soon.

[x-ji]

I uploaded the new file. You should be able to produce a local deployment and test it now.

Though if you just want to develop new versions as a developer, you would normally just run phx mix.server in the project directory and run the app under dev environment. You'd need to create the corresponding Postgres DB first, or grant the babe_dev user the privilege to do so, before running mix ecto.create, mix ecto.migrate. Programming Phoenix or just the Phoenix official website should have a walkthrough on this.

[JannisBush]

Thanks, I will have a look at it

[x-ji]

I've written instructions in the README. Please take a look and see if there's something inaccurate in there. In general for the developers it makes sense to run the app in dev mode instead of trying to use deployments locally.

[JannisBush]

Sorry for my late reply.
I installed postgresql with apt, but the instructions on the arch linux forum for step 2, didn't work for me.
Then I just skipped step 2 and did the other steps. Now the server seems to work, but it throws some errors.

While running: mix deps.get; mix ecto.create; mix ecto.migrate
** (Mix) The database for BABE.Repo couldn't be created: ERROR 42501 (insufficient_privilege) permission denied to create database.

While running: mix phx.server
[error] inotify-toolsis needed to runfile_systemfor your system, check https://github.com/rvoicilas/inotify-tools/wiki for more information about how to install it. If it's already installed but not be found, appoint executable file withconfig.exsorFILESYSTEM_FSINOTIFY_EXECUTABLE_FILE env.

However, it appears to be working fine.

[x-ji]

Did you grant the privilege to create DB to the user babe_dev with ALTER USER babe_dev CREATEDB;? If not then it doesn't have the privilege.

Though if you created the database as the user postgres and granted the privileges on that database to babe_dev, you don't need to let babe_dev create that DB whatsoever, i.e. directly running mix ecto.migrate should be enough.

[JannisBush]

I did not grant the privilege using ALTER USER babe_dev CREATEDB;, because I already used the other method.
Okay, this makes sense :)