search

dhardy / pippin

a distributed-merge capable database for many small objects
ISC License
78 stars 4 forks source link

Additional info #27

Closed dhardy closed 8 years ago

dhardy commented 8 years ago

Some operations may wish to report additional info besides their main effect.

Examples

Some element get/insert/etc. operations may require loading additional partitions to do their work. In this case it's just informing the user that the operation could be slow and giving them a chance to cancel it.

Replacing an element with a different value could result in the identifier changing (since it could be placed in a different partition). Repartitioning may result in element identifiers being updated. Additionally, while finding an element, the library may discover that an it now has a new identifier (which allows faster look-ups). (There's also a chance for interaction here: there's a chance the user may be able to make a better guess about where our element ended up than the library can.)

Strategies

Naive

The straightforward strategy would be to modify the return types of all methods which may have additional info. This could make usage tedious and might mean the user would often forget to check it, but in any case this is only advisory information.

Additional loading could be done without informing the user just with a configurable policy (load or abort).

Message queue

A message queue could be attached to the Repo type for the user to check any time they like after the operation has completed. This would be fine for warnings (so long as the code reporting has access to the repo) and should be okay for advisories about new identifiers.

Interupt handler in a different thread

The user could set some code to run in a different thread as an interupt handler. This thread should be dedicated to "interupt handling" since other code may block waiting for it. Some kind of lock would be used to update a shared memory block with details of the issue, the handler would be triggered, update/clear the shared memory, and return control to the interupted code (perhaps with a status code).

This strategy is complex, is dependent on available threading facilities and is prone to bugs both in the implementation and on the user side (e.g. trying to use the library from the handler causing a dead-lock).

dhardy commented 8 years ago

I think this has to come directly through the method. Currently the UserFields and MakeMeta traits are for this kind of thing.