[FAQ] - Migration/Synchronization Between Two or More QLog Instances

[foldynl]

Q: Is it possible to synchronize different QLog instances?

A: Unfortunately, it is not possible at the moment. Currently, the only way to achieve this is through the use of Export/Import.

However, this is something I've been analyzing. It is definitely at the top of my priorities, but this task is a bit more complex than it may seem. Hopefully, in the near future, the first step towards addressing this challenge will be introduced.

[rsaue]

Hi,
With CQRLOG and Log4OM I achieve this using MySQL database... Makes it possible for me to operate my local station and my remote station at the same time with the same log. Would be a nice addition to QLog too.

73 de LB2EG Richard

[foldynl]

yes, I know this approach mainly from CQRLog because I originally used CQRLog. This approach has several advantages but also several disadvantages. These disadvantages and the other things, especially the CQRLog development cycle, are responsible for why I do QLog

Advantages:

• MySQL (mariadb) acts as central point for various applications, not only for Log Application.
• MySQL can handle multiple read/write clients (applications)
• MySQL contains a more advanced SQL language implementation

Disadvantages:

• MySQL is a server application which, in my opinion, is too advanced for the purpose of any log file application
• unfortunately, in my opinion, most users struggle with the fact that they have a SQL server running somewhere.
• to have one shared DB, it is necessary to properly configure this database in order to be able to expose it to the Internet. To be honest, I have some experience with installing MySQL/MariaDB and I would never expose it directly to the internet. It means that, I lose the possibility of having one shared database for log application.
• I expose the user to unnecessary effort when migrating between versions of MySQL. Sometimes it happened that when upgrading MySQL it was necessary to "(re)configure" new properties in the MySQL configuration files. sometimes this task requires knowledge that I cannot expect from the average user.

SQLite database was originally chosen for QLog, which I think was a good choice for this type of application. Yes, I know SQLite has also significant disadvantages. But it has significant advantages.

• it is pretty easy to manage - no knowledge of advanced settings is expected from the user.
• the user does not have to set anything. Everything can be done from the application.
• the concept of one file, one database is simple and understandable even for users.
• it can be operated on MacOS, Windows and Linux - it is important to keep in mind that QLog is multi-platform.

Currently, I have no plan to implement a "remote" database for QLog. I would like to fully concentrate on how to synchronize the QLog database without the need to have a central point. It is really a considerable challenge and it is hard to say whether it will be successful.

[rsaue]

LogHX3 log (windows only http://rx4hx.qrz.ru/) uses a local access format log. The software has an option to run more instances with separate configurations, using the same log with mutual exchanging log data using different ports for sending and receiving.

Works quite well. Maybe something to look into.

73 de LB2EG Richard

[rsaue]

Hi Ladislav,
As i have no actual programming skills, I might fail to understand the limitations of the sqllite database system. Reading item 5 of the faq at www.sqllite.org, gives me the impression that while only one app can write to the database, more apps can read the database at any given time.

If this i true, you could have a main Qlog program as today, that reads and writes to the log database. Then you have a slave version of Qlog, with independent set up files, that reads the main log database, but does not write to the log database. Instead it sends new log data with UDP to the main QLog program, or writes new log data to an ASCII ADIF file which the main program reads and writes changes to the log database. The slave instance of Qlog must be setup to read and update the wiew of the main log as soon as log data is applied to the main log database.

What say?

73 de LB2EG Richard

[foldynl]

excuse my brevity, but the master-slave architecture does not solve the synchronization. It is only intelligent export/import.

Synchronization in my thinking is that it will not matter which instance you work with. You will have everything in all instances. This is the correct concept of synchronization. If you do something somewhere, it has to be transferred to others by itself.

The problem is more complex because you have to solve update conflicts (you update 1QSO on two different instances) and other concurrent problems.

[pulponair]

Late to the Party, but here are my 2 cents:
I totally agree using MySQL is simply to bulky for most use cases. But what about using a DBAL Layer having a sqlite default configuration? That would enable advanced users to use what ever storage backend they want. If i want a MySQL remote instance, fine, i just configure the DBAL to use it without the application having to know about it. thoughts?

[foldynl]

To be honest, I don't find an external database useful in terms of usability. I can already see that the mindset of multiplatform development is quite limiting. I can't really imagine how such a external database would be supported. Imagine a situation where you support 3 platforms, the Linux platform has several sub-variants and each is somewhat specific. Adding the option of a universal database will only increase the difficulty for testing and support, but the benefit for the average user is minimal.

Therefore, I think that the external database approach would not be on roadmap now.

To present my thinking here. Just one note, these are just ideas, the final solution may be different. I like rqlite or litesync (licensed; not possible to use) approaches. Nice ideas are also superfly but it is not a multiplatform or aergolite - blockchain database based on sqlite.