deleting stuff in a database would be nice.
however, there are multiple ways to do this:
- deleting entries from an IODatabase wouldn't actually mean that the space allocated to them is gone, the index of the entry would get replaced by a jump instruction (and perhaps the entries around it) to more indexes. this wouldn't be that easy to do since the jump instruction is only an integer, so if you have files bigger than 2GB you wouldn't be able to jump to an index to the future, and even more far off jumps would have to be made.
- move all of the data of the stream over the old data, completely overwriting it and properly deleting it. this would involve changing of lots of positions and relative jump locations, so a delete would prove a costly operation.
moreover, an API for deleting would be complicated. currently, the suggested route is to pass in multiple ILazyLoader[]s to Delete, but then you'd have to manage existing ILazyLoaders to ensure that the relative positions they store get updated as well.
perhaps it'd be better if you'd be forced to close the database, and do separate deletion operations via an entirely different class, forcing developers to adapt to a different, more appropriate style.
StringDB isn't designed to be used to constantly add/remove stuff, and it'd be a more appropriate workflow to be forced to close the database, then modify it, then re-open it.
a current workaround is to and add all the things you want in the new database that aren't the deleted items.
deleting stuff in a database would be nice.
however, there are multiple ways to do this:
moreover, an API for deleting would be complicated. currently, the suggested route is to pass in multiple ILazyLoader[]s to Delete, but then you'd have to manage existing ILazyLoaders to ensure that the relative positions they store get updated as well.
perhaps it'd be better if you'd be forced to close the database, and do separate deletion operations via an entirely different class, forcing developers to adapt to a different, more appropriate style.
StringDB isn't designed to be used to constantly add/remove stuff, and it'd be a more appropriate workflow to be forced to close the database, then modify it, then re-open it.
a current workaround is to and add all the things you want in the new database that aren't the deleted items.