Hi, see below:
Am Fri, 29 Dec 2023 03:20:05 +
schrieb Drew Arnett :
> tangent: Variable length fields are handled easily with line
> separators delimiting records and space, comma, tab delimiting fields
> in a record. It may be the UI (especially a TUI) where expected max
> field length may
I was ignoring the utility of SQL/RDBMS operations. (Am I
misremembering or are there libs to do that with flat text "table"
data structures already?)
I like that sqlite "how to corrupt" article. It does point out very
well that data safety isn't simply application level
question/architecture/so
* On 2023 28 Dec 13:07 -0600, Christoph Berg wrote:
> But sqlite is not a networking database. If you want that, use
> PostgreSQL.
I've been using the WeeWX weather station processing software for nearly
nine years and it prefers to use SQLite for its DB. It also supports
Mysql/Mariadb. Recently
Am Thu, 28 Dec 2023 20:06:42 +0100 schrieb Christoph Berg
:
> Re: Thomas Beierlein
> > Two points here:
> >
> > - Journaling is easy, but to be honest TLF provides quite some
> > robustness in that sense too. I have not heard any complies about
> > lost data in all the years.
>
> Some t
Why do you want access to database over network? Any benefits from such
solution?
Still it's always easier to migrate in te future to PostreSQL or MySQL from
SQLite. So from my pov small steps ahead, not big jumps :)
Wondering why syncing tables/databases over network are worst than db access
Re: Thomas Beierlein
> Two points here:
>
> - Journaling is easy, but to be honest TLF provides quite some
> robustness in that sense too. I have not heard any complies about
> lost data in all the years.
Some time last year, I was auditing (well, reading) the tlf source to
check that. There
* On 2023 28 Dec 08:57 -0600, Alan Dove wrote:
> Hey, folks:
>
> I'm opposed to having TLF rely on a database. It adds complexity and
> failure points, and shouldn't be necessary for any forseeable contest
> log.
I think this is a good point particularly in the logging space where Tlf
is mostly u
Hi,
On Thu, Dec 28, 2023 at 03:53:14PM +, Marcin SP6MI wrote:
> Hi,
> Shared database is wrong idea on my opinion, but syncing multiple database or
> tables should be easier,
I'm not sure about that.
* it is completely outside the user-controlled area (from the
view of Tlf)
* building a s
hi all,
On Thu, Dec 28, 2023 at 09:56:44AM -0500, Alan Dove wrote:
> Hey, folks:
>
> I'm opposed to having TLF rely on a database.
to _RELY_ on a database, yes, I don't support that.
> Users who want a tool to collect QSOs from multiple contests for
> analysis, DXCC tracking, and so forth shoul
See answers inline.
Am Thu, 28 Dec 2023 15:39:54 +
schrieb Drew Arnett :
> Would a database store offer any useful utility? Journaling or ? for
> robustness?
Two points here:
- Journaling is easy, but to be honest TLF provides quite some
robustness in that sense too. I have not heard a
When I first read the proposal to add a database to TLF, I must admit that
I silently moaned an "Oh, NO!!" But if it makes your work easier ... :-)
I'm too old for contesting, but that may change. ;-)
On Thu, Dec 28, 2023, 9:47 AM Thomas Beierlein wrote:
> It is true that the mentioned use of a
Hi,
Shared database is wrong idea on my opinion, but syncing multiple database or
tables should be easier, safer and faster than textfiles.
In the future maybe whole configuration + log per contest can be stored in one
database file.
Nr
Marcin SP6MI
Wysłano z aplikacji Proton Mail
Ory
It is true that the mentioned use of an external database adds some
complexity and problems. These data bases are well equipment for
handling LARGE number of data elements (e.g. your whole qso history as
in case of CQRLog).
What we discussed for TLF was mostly the use of an sqlite database
which w
Would a database store offer any useful utility? Journaling or ? for
robustness? Power loss during portable contesting with a laptop or
desktop or Pi or ? ... would be nice if no data loss and simple
resumption after power is restored. Or is the choice of
HW/OS/filesystem more useful for that so
Hey, folks:
I'm opposed to having TLF rely on a database. It adds complexity and
failure points, and shouldn't be necessary for any forseeable contest
log.
Users who want a tool to collect QSOs from multiple contests for
analysis, DXCC tracking, and so forth should use a separate
application. CQR
Hi all,
On Thu, Dec 28, 2023 at 12:10:43PM +, Csahok Zoltan wrote:
> Hi,
>
> I see currently no issue that introducing a DB backend would solve.
> Technically for 1k records and holding it in memory no DB is required.
it's not an issue - my idea was to collect all of my QSO's from
each logs
Hi,
I see currently no issue that introducing a DB backend would solve.
Technically for 1k records and holding it in memory no DB is required.
One thing, on the other hand, that is now seriously broken is the networking
support. I requires a careful rework, including probably a redesign
as it app
Hi,
Thank you Ervin, if it's not a problem I would like to show your code.
Br
Marcin SP6MI
Wysłano z bezpiecznej poczty e-mail Proton Mail.
środa, 27 grudnia 2023 22:19, Ervin Hegedüs napisał(a):
> Hi OM's,
>
> On Wed, Dec 27, 2023 at 10:06:13PM +0100, Thomas Beierlein wrote:
>
> > Hi Mar
Hi OM's,
On Wed, Dec 27, 2023 at 10:06:13PM +0100, Thomas Beierlein wrote:
> Hi Marcin,
>
> the move to a database representation of the log file was discussed
> some month ago. It got some pro and con arguments.
>
> Therefore there was no final decision to implement it. For the time
> being we
Hi Marcin,
the move to a database representation of the log file was discussed
some month ago. It got some pro and con arguments.
Therefore there was no final decision to implement it. For the time
being we will stay with the actual log file format.
Seems we missed to drop it from the ToDo list
20 matches
Mail list logo
