dummy dataset

[ghost]

Hi im looking of a dummy hamster.db with all the possible usecase for testing and presentation. If anyone have one at home :)

[GeraldJansen]

You can easily create one as follows:

1. stop hamster (eg. pkill -ef hamster)
2. make a backup copy of your current hamster.db
   mv ~/.local/share/hamster-applet/hamster.db ~/bu-hamster.db
3. restart hamster (which will create a new empty DB) and then enter some example activities
4. stop hamster again and save your entries as a dummy-hamster.db
   mv ~/.local/share/hamster-applet/hamster.db ~/dummy-hamster.db
5. restore your backup copy, then restart hamster
   cp ~/bu-hamster.db ~/.local/share/hamster-applet/hamster.db

Of course, to do testing/demonstration, you'd need to put the dummy-hamster.db back as ~/.local/share/hamster-applet/hamster.db, which is a real bother. You could automate this with scripts, softlinks etc.. However, it would probably be best to have a separate environment for testing/demo, say a dedicated userid or a separate VM.

Edit: see below for a variation on the theme which exploits live swapping of the DB.

[GeraldJansen]

Suggestion added to tips-and-tricks. Can this issue be closed?

[ederag]

Thanks Gerald.
It might be useful to precise "restart hamster". hamster-service precisely, isn't it ?

The OP was asking for a database, so it looks like the issue was not how to use a separate database,
but rather the important part was

all the possible usecase for testing and presentation

I would like this too, and as you said a separate virtual machine is nice and safe.
Yet that would require to go to the exact dates stored in this database.

To me the perfect testing tool would require

1. ability to chose a database (as an option to hamster-service, only one at a time, need to restart).
2. generation of a test database based on relative datetimes, from today. That could be a waf command.

[GeraldJansen]

Okay, sounds good, even if your request for a "perfect testing tool" seems to go well beyond providing a "dummy dataset" as requested by the OP.

It might be useful to precise "restart hamster". hamster-service precisely, isn't it ?

I tried to keep it simple. Instruction 1. will kill hamster-service and restarting hamster in any way restarts hamster-service automatically.

all the possible usecase for testing and presentation

That would be a nearly infinite space :-) One might have to scaling down a bit, say to "numerous test cases".

[ederag]

To me the perfect testing tool would require

I was listing necessary, not sufficient conditions 😄.

Instruction 1. will kill hamster-service

True. Yet I find it more pedagogical to state hamster-service
since that would make it very clear who is handling the database.

restarting hamster in any way restarts hamster-service automatically.

That is not the case when using src/hamster-service, but this works for an installed hamster ?
Interesting.

Anyway, changing the database "live" (file monitoring) does work now, doesn't it ?
(no need to restart anything).

[GeraldJansen]

Hmm, [src]$ pkill -f hamster && ./hamster-cli [command] works for me, just like pkill -f hamster && /usr/bin/hamster [command].

One can replace the database "live", however, deleting the database while hamster-service is running doesn't seem to automatically recreate it from the empty template DB (at least I have had problems trying that).

[ederag]

Ok, I did not noticed that it was meant to create the database.
Your solution works without having to download the repository.
but that is a somewhat convoluted way to do that;
copying data/hamster.db to .local/share/hamster-applet/ is a bit simpler,

# clone the repository (https way; ssh or zip file are available from the main page)
# into a hamster directory
# step not necessary if you already have the development version of course
git clone https://github.com/projecthamster/hamster.git hamster

# backup current database
cp ~/.local/share/hamster-applet/hamster.db hamster_backup.db
# overwrite main database with test one
mv hamster/data/hamster.db ~/.local/share/hamster-applet/hamster.db

# test, ...

# done; get the dummy database
cp ~/.local/share/hamster-applet/hamster.db ./dummy-hamster.db
# move back original database to main
mv hamster_backup.db ~/.local/share/hamster-applet/hamster.db

Well, a bit clearer with respect to purposes,
and this can be generalized to use any test database.

[GeraldJansen]

Okay, updated the wiki page.

W.r.t. automated creation of test cases with recent dates, one can create -nnn/+nnn relative timestamps in a bash script, as in the following example:

# function for relative timestamp (arg -nnn or +nnn minutes)
function rts() { echo $(date +%Y-%m-%d\ %H:%M -d"$1 minutes"); }
# test of embedded activities 
hamster track 'outer activity@test, testing embedded activies #dev' $(rts -60) $(rts -10)
hamster track 'inner activity@test #dev' $(rts -60) $(rts -30)
# future activities too!
hamster track 'test@ABC/Cooker' $(rts +0) $(rts +30)
...

[GeraldJansen]

Suggestions have been added to tips-and-tricks. Can this issue be closed now?