This function is used in debug mode to print the current status of the
index. I also created a print_keys() function to only list the keys.
Signed-off-by: Anna Schumaker <schumaker.anna@gmail.com>
Other tests may need to print out a database. To make this easier I've
added a print() function to the base database class. This function will
only exist when CONFIG.TEST == True, so don't use it outside of testing!
Signed-off-by: Anna Schumaker <schumaker.anna@gmail.com>
I was using my own cpp file to remove old test data to start with a
clean slate. I've decided it's easier to just remove the files before
running tests if they exist.
I also use this patch to update the test design and add an idea for the
future.
Signed-off-by: Anna Schumaker <schumaker.anna@gmail.com>
The library will need databases that have unique values (such as the
artist or album tables). This patch adds support for that in my
existing database code.
Signed-off-by: Anna Schumaker <schumaker.anna@gmail.com>
The idle queue is used to schedule tasks ... later. This code was
mostly adoted from a reference TDD experiment by Josh Larson
(themutatedshrimp@gmail.com). Thanks Josh!
Signed-off-by: Anna Schumaker <schumaker.anna@gmail.com>
I only handle the "All Music", "Library" and "Banned" groups at the
moment but I'll eventually add in more features (in future versions).
Signed-off-by: Anna Schumaker <schumaker.anna@gmail.com>
I still have some back-end work to do first, but I should start thinking
out what users will see.
Signed-off-by: Anna Schumaker <schumaker.anna@gmail.com>
I have everything except for save() and load() written. My unittest is
fairly comprehensive and tests everything implemented so far, so with
any luck putting in save() and load() features will go quickly.
Signed-off-by: Anna Schumaker <schumaker.anna@gmail.com>
- Save recent database changes
- Move the idle queue after the database
- Put file class definition notation
- Update the todo list
Signed-off-by: Anna Schumaker <schumaker.anna@gmail.com>
I had planned on using the stream operator for my database class but
this created some crazy compiler error that I was having difficulty
figuring out. I decided to take the easy route for now and instead
create read() and write() functions that do exactly the same thing.
Signed-off-by: Anna Schumaker <schumaker.anna@gmail.com>
A database may have invalid rows. If this is the case, then the next()
function needs to return the id of the next valid row. I'm aware that
this could get horribly inefficient on large DBs with many invalid rows.
I don't expect people to delete large chunks of music all at once, but a
defragment tool is on my "todo" list for a future Ocarina version.
Signed-off-by: Anna Schumaker <schumaker.anna@gmail.com>
I've been excited about this! I think it'll be a better design than
what I had for Ocarina 5.x.
Signed-off-by: Anna Schumaker <schumaker.anna@gmail.com>
I need a way to return the progress of the idle queue and to indicate
when it is out of tasks so idle threads can stop running.
Signed-off-by: Anna Schumaker <schumaker.anna@gmail.com>
I changed print to compile in the dprint() function when the testing
flag is enabled. This allows tests to have the same output regardless
of debugging status.
Signed-off-by: Anna Schumaker <schumaker.anna@gmail.com>
- Inherit from fstream to gain access to << and >> operators.
- Make the file version accessable to the outside world.
Signed-off-by: Bryan Schumaker <bjschuma@gmail.com>
- Support OPEN_READ and OPEN_WRITE
- Update the design to accomidate for error checking
- Add lib/test.cpp containing basic functions that can be used for
testing
Signed-off-by: Bryan Schumaker <bjschuma@gmail.com>
I'm starting to implement file access. I've reread the design and
updated a few things to make it easier to test.
Signed-off-by: Bryan Schumaker <bjschuma@gmail.com>
This will give some better stability to the design document, since
entries won't shift around based on python memory locations.
Signed-off-by: Bryan Schumaker <bjschuma@gmail.com>
Each component has its own text file. I merge everything together with
simple dependency resolution so I can figure out implementation order
easier.
Signed-off-by: Bryan Schumaker <bjschuma@gmail.com>