Solved Cancelling events according to results of a database qurey

Discussion in 'Spigot Plugin Development' started by robertlit, Jan 26, 2020.

  1. How would I go for cancelling events after checking some values in the database, so, of course the database query is run async and it returns a CompleteableFuture. The thing is, by the time I get the result from the database it'll be too late to cancel the event. So I suppose actually cancelling the event is impossible.
    Any thoughts on how to replicate the cancelation?
  2. I mean you can just wait until the database-object is there...
    Code (Text):
    while(!querry.isDone()) {}
    This will obviously stall a lot of things, but then that's the price you'll have to pay.
    Another option is to store whatever event you are trying to cancel; let's say it's a BlockBreakEvent and you want to cancel the event. You'll need to store the Block and when you have the result, reset the block to a previous state. This is obviously gonna get hard when there are multiple events that can happen; you'll then need to have a queue with all of the blocks in it.
    The best option is obviously to pre-load whatever it is you are looking for in the database.
  3. I might as well run the task synchronously.
    That's what I thought of, I guess this is the best option, although it could sometimes cause bugs..
    I wish that was possible, but in my case it's just not, I can't keep in cache so much data.
  4. What kind of sizes are you talking about? You can always try and shrink the sizes by reducing some sort of redundancy or applying sensible compression methods.
  5. Each block has durability, each time it's broken its durability gets reduced by one and it gets restored, if the durability is 0, the block gets borken.
    (Of course, only blocks that have been broken are stored, but still, I can't keep this in cache)
    For preloading, let's each time a player enters a chunk I will load the data of all blocks inside that chunk to cache, what if the chunk has 1000 blocks broken and there are 100 players on, I can't keep this much in cache.
  6. 1000 blocks * 100 players = 100.000. Assuming you can be very efficient and the durability can be represented by one byte, you have a memory overhead of 100 kB; 0.1 MB. And I doubt that these numbers represent a realistic scenario. Also, you don't need to store all the blocks, only the ones that are broken. If the blocks have a durability of 0, you can just throw em away from the heap.
  7. That's what I do :)

    Thanks, for the idea, I will try to implement this.