Inserting into a vector can sometimes cause the entire vector to
reallocate itself. The insert() function returns a pointer to the
caller, so this reallocation could invalidate the returned pointer.
This is not what we want.
Instead, store pointers to the data in the vector. C++ provides a
default copy constructor that can be used to allocate a new item before
inserting. By doing it this way callers won't have to allocate memory
themselves. In addition, I will no longer need to keep a valid bit
since we can simply check for a NULL entry in the database.
Signed-off-by: Anna Schumaker <anna@ocarinaproject.net>
This will let me set up a Track class that has pointers to the
corresponding artist, album and genre information without needing to
know their IDs directly. Having this information available means I
won't need to keep a "join struct" when doing lookups - instead I can
return a pointer to a Track class that already knows everything.
Signed-off-by: Anna Schumaker <schumaker.anna@gmail.com>
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 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>
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>
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>