Open kingsley-einstein opened 4 years ago
@yivo What do you think about this approach? I personally think DBs such as MySQL and MongoDB should not be used for the queuing and tx management, but as permanent storage to keep validations, failures, and tx details. This should also be optional. I also think to add DBs will make this library more of a "system" rather than transaction management. One idea could be to add another repo that uses this lib to store results in DB.
@bashash I think databases like Mongo and MySQL are too specific stuff to implement here. And it's also not as easy: we need to manage migrations, different DB versions can cause issues, much more stuff to do for local development (and production deployment actually).
Instead of trying to put every possible method of saving data (Redis, Memory, Disk, MySQL, Mongo etc) we need to just provide simple interface which can be used by developers to add their own storage.
It can look like this (just example):
interface SologenicDatabaseInterface {
function connect() {}
function addTxToQueue() {}
function getQueuedTxs() {}
function deleteTxFromQueue() {}
}
class SologenicMySQL implements SologenicDatabaseInterface {
function getQueuedTxs() {
// SELECT * FROM txs ...
}
}
Then you specify in config:
{ database: new SologenicMySQL(mySQLConfig) }
It can be easily integrated with anything you want ever decentralized database and adapters can be distributed in separate NPM packages.
@yivo @bashash
Creating an implementable interface would mean the developer would have to write raw queries themselves?
@kingsley-einstein No, developer will use library as usual. He doesn't know what is going on in the internals of adapter, he just uses simple functions to save/edit/delete data.
Feature
#1
Developer can indicate store to use. There is presently support for Redis, Hash and Memcache.