I updated the design and rewrote the unit tests. This creates something
more consistent with how I ended up using the index.
Signed-off-by: Anna Schumaker <schumaker.anna@gmail.com>
I add:
- Autosaving option
- Real iterators
- Better accessor functions
The new design and unit test also allows me to remove the 300,000+ line
"database.good" file that the old tests were based on.
Signed-off-by: Anna Schumaker <schumaker.anna@gmail.com>
I changed primary_key() into a function since it is only called once,
and there is no point in using more mmemory than I need to. I also
created a basic unit test for everything that database entries are
supposed to do.
Signed-off-by: Anna Schumaker <schumaker.anna@gmail.com>
I changed the two playlists that are supported, added in exception
handling, and removed the list() function since I will always know the
names of playlists. I also rename everything to "playlist" from
"group".
Signed-off-by: Anna Schumaker <schumaker.anna@gmail.com>
This patch updates the design so indexes are built upon databases using
a special IndexEntry. I also updated the tests/index/ test to match
the new system, but I have not updated filter or group tests yet.
Signed-off-by: Anna Schumaker <schumaker.anna@gmail.com>
I require entries to have a "primary key" that is stored in a map to
make it easy to find database rows by key.
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>
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>
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>
Items will be marked "invalid" rather than directly removed from the
database. This make it easier, since I won't need to reassign IDs to
every database item after the removed one.
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>
Anna Schumaker