Please read last post and maybe the one before it for context. This is the last post of 3.
Insert before looping over custom_YOson.tick:
from sqlalchemy import event
@event.listens_for(db.Block, 'after_insert')
def do_after_insert(mapper, connection, block):
print('inserted:', block.num)
Instead of print(), plug in whatever.
For a YO app, I'd listen for Yos instead.
This is thread safe at least when using the same engine for all threads (using Python for threading).
Anything you plug in here will be executed right after the SQL commit.
That's it.
In the first post, I talked about just running 2 separate instances of the same service.
For that, the above approach wouldn't work anymore.
At which point I'd have to use a task queue of some sort.
For SQLite I'd need to build a handler that takes jobs from a queue and move the responsibility of SQL stuff from custom_YOson to the handler. And plug in my app there. Likewise, with an SQL server, I could plugin my app server side.
At any rate, moving SQL responsibility upstream and further away from custom_YOson would be best to improve this further. Before that, improving on the Hive api part of it would be much more important, and for that I'd probably use a similar approach...
For a task queue maybe Redis would be better than another SQL table.
And whatever I plug in, at the end I'll probably at least want to store if that thing executed. I'd need some other storage again.
All that stuff isn't Hive related.
There are better guides for all of this and I wouldn't even be the right guy to write about it.
I mean last post, for example, I already messed up: Yo.author should also be a foreign key, authors should have their own table.
I could continue hacking together some form of engine around block_api... I have.
But I shouldn't be writing 'guides' on this stuff.
I need to change the title of these posts...
You could look at Hive as a game engine. You could certainly use it as one.
In a sense, Hive is a game:
Posting and curation is a game; The posting reward pool is a prize pool.
Posts, votes, transfers, custom_json are all operations and are stored inside blocks.
As a game engine, Hive has a tick rate of 0.33, or one tick every 3 seconds.
That's slow, but it can do some cool things.
I've written 3 posts, containing 100 lines of code of which the part about Hive is still only 4 lines.
Other than maybe being inside of a node, the most reliable and fastest way to get to the blocks is this one call. In Python that could be done in 1 line.
The health of the response mostly depends on the source, not the Python code.
If the above call is successful, the response contains blocks.
The blocks could contain nearly anything, from offensive words to malicious code.
It's kind of raw.
Last post, by declaring fairly restrictive data types to the classes Yo and Block, I have made at least the stored data reasonably safe from that angle. If there are any surprises, the program just breaks.
The block api is powerful, but you may need more than a library to use it cleanly.
I'll keep writing about that, but some place else.
As far as this series, I'll start using a different title:
'Small coding adventures: Exploring Hive as a black box'
...or something like it...
What I really wanted to get across:
You don't have to use a library, you don't have to build around one, maybe you shouldn't or can't, but instead: Build around the blockchain.
If you build on the Hive blockchain there is a price to pay:
For the fee, you can get cheap and easy stuff later, maybe for free, maybe even profit.
Hive comes with a lot of cool features, but to really use them, you'd have to design based on them.
Because otherwise it would probably be also kind of pointless to build on something this slow and sometimes even clunky.
What could and should be built and how, sometimes can be best explored by hacking away at it. At least that's what I'll keep trying to demonstrate here. But in single posts, no more 3 part series.