Using an embedded database may be a better choice about bridger

[wi1dcard]

Personally, I prefer to use a database, or at least use a JSON file and write the data to the file periodically. Here are some of my thoughts:

1. There's one major issue that you have to take much care about in a public client instead of a private project - the compatibility. What if sometime in the future we add, let's say, a feature that includes more complex data that has to persist on disk, how should you store them into a text-based lock file? If we decide to use a DB or something else at that time, will the migration workload be too much for us?

2. Also, as @wuminzhe mentioned, there could be a chance that the program exits without any signal came out like it crashes, or even you did receive the signal, but it can't be properly caught or handled, for example the SIGKILL.

3. Another thing you'd have to think about is - you can't write data to disk synchronously, but periodically. Otherwise, the disk IO can be too high.

4. The bridger is not a binary-size-sensitive software in most common cases, I don't think there will be many users running it on a device that has little disk spaces.

In my opinion, all the issues above have already been taken care of by almost every common database engine.

Although using a DB looks unnecessary at the moment, it can save lots of "Engineers' time" for a longer-term plan. To put much more costs of engineering on reducing sizes of final binaries for just several MB, I'd rather choosing importing these dependencies.

[clearloop]

It's not about the future thing, it's about what can solve problems exactly, clean, efficient, and elegant.

For example, if we are riding on the land, why should we spend time building our motorcycle can ride on the ocean, in the future? The core problem is riding on the land more safely and stable, not thinking of adding an air cushion to it to avoid dropping into the water.

And in a word, using a database or a file is not an arch problem, it is a very little thing, and It could be converted from file to DB or DB to file in 10mins, anytime, easily.

I can't understand why we spending time thinking about using DB or file instead of checking the logic of bridger.

It is sync all the time.

It is only a binary.

[clearloop]

File IO can handle this, the database solution is dirty.

[wuminzhe]

How to solve the problem of the need to change the configuration after a restart?

[clearloop]

How to solve the problem of the need to change the configuration after a restart?

Listen to the exit signal and updates the config file, or a redeem.lock file.

[wuminzhe]

dirtier!

[clearloop]

dirtier!

Using a database to store a number is like buying a house to store a cigarette, all we need is a cigarette case.

[wuminzhe]

not a number, but a tx list. you store the list in memory now. and you can do more things based on the list in the future like show a ui to the user more stable.

[wuminzhe]

and, maybe there is no exit signal.

[clearloop]

not a number, but a tx list. you store the list in memory now.

It's a FIFO queue, first in and first out.

and you can do more things based on the list in the future like show a ui to the user more stable.

We don't have a specified UI plan now, so we don't need the database.

For SQLite, it requires the sqlite3 link library for UNIX, for Rocksdb, it is too big(including link library), Sled is okay but still unnecessary.

---

And storing the queue is unnecessary as well because whatever happens we always have the first request to the Ethereum, the queue is temporary all the time, it should be placed in memory.

[wuminzhe]

and, easy to debug data from the user's machine.

[wuminzhe]

easy, just a suggestion

[hackfisher]

#32 bridger's ethereum block start will need a data store for persistence, agree with @wi1dcard opinion, local light db is better than file.