cache_size being passed to json

[jmjuju]

Hi Guys,

I'm using tiny db which is being updated by one script and read by another. Because of this I am using
db = TinyDB('filename.json', cache_size=0) because otherwise the reading script doesn't get the updates/changes the the writing scripts does, as per https://tinydb.readthedocs.io/en/latest/usage.html#query-caching

However, when it comes to writing to the db, I then get __init__() got an unexpected keyword argument 'cache_size' errors, because all arguments are passed to json.dump(), as per the hint in https://tinydb.readthedocs.io/en/latest/usage.html#storage-types

Any suggestions on how to avoid this conundrum? Should I instantiate two instances, one with cache set to 0 for reading, and one without the cache_size arg for writing?

[msiemens]

Hey @jmjuju,

thanks for bringing this up. The documentation doesn't make this very clear but the cache_size parameter has to be passed to the db.table(...) function, not the TinyDB constructor:

table = db.table('table_name', cache_size=30)

But, it turns out that there's some weird behavior with this in TinyDB. Namely, you cannot open the default table (which is used when db is used directly to store data) with a custom cache size. This is because the table objects are cached upon first use which means that the table object for the default table is created upon construction of TinyDB.

I'll have to think a little about how to best solve this.

As a workaround you could use a different table and pass a custom cache size there, see https://tinydb.readthedocs.io/en/latest/usage.html#tables

[msiemens]

But, it turns out that there's some weird behavior with this in TinyDB. Namely, you cannot open the default table (which is used when db is used directly to store data) with a custom cache size. This is because the table objects are cached upon first use which means that the table object for the default table is created upon construction of TinyDB.

I've just checked again and found this to be incorrect too 😉 The actual issue is that you cannot cannot open the same table multiple times with different query cache sizes (or other parameters). This actually makes sense as there is runtime information that would run out of sync if two Table instances would try to write to the same table in the same file. Most importantly, both tables would keep track of the next free document ID separately and thus writing to one instance of the table and then the other one would lose data.

So basically this is by design, but surely the documentation on this could be improved.