xlog-discussion
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xlog-discussion] xlog-0.9 released


From: w9ya
Subject: Re: [Xlog-discussion] xlog-0.9 released
Date: Tue, 18 Nov 2003 22:33:26 -0500
User-agent: KMail/1.5.4

On Tuesday 18 November 2003 08:15 pm, Nate Bargmann wrote:
> * address@hidden <address@hidden> [2003 Nov 18 17:04 -0600]:
> > > Due to moves in life I now have QSO data that span two calls, four
> > > permanent QTHs, and numerous mobile contacts that I've noted at least
> > > my transmitting county in case of QSL requests.  This is relational
> > > data (at least that's how I understand it, I could be wrong) as there
> > > is at least one and probably more QSOs per transmitting location.  An
> > > RDBMS seems to me to be a powerful way to tie all of this together so
> > > that I can do searches of my log data in a number of ways.  As I am a
> > > neophyte to the ways of RDBMS, I assume that building such things as
> > > indices between tables allows this magic to happen.
> >
> > Again, I am asking for specifics as to what information you are looking
> > to evaluate and how ? In other words "....so that I can do searches of my
> > log data in a number of ways." is not informative as it isn't specific.
>
> Since I'm not currently using computer logging outside of CT for the few
> contests I participate in, this may still be vague.
>
> I would like to be able to sort and print (perhaps more) the QSO data on
> a "by TX QTH" basis.  There are the other common sorts of by band, mode,
> callsign, date, etc.  It would be nice to be able to order this by any
> arbitrary criteria (SQL is a standard language and SQLite supports a lot
> of it.  Also much sorting and display work can be done outside of Xlog
> through the sqlite utility.).  Again I think it's important to track the
> TX QTH so QSL and award tracking for me or the other station can be as
> accurate as possible.
>
> > > As it is now I have to be sure to enter my transmitting location in
> > > Xlog in a consistent manner so that searching the log would reveal
> > > something useful.  An alternative is a seperate log file for each
> > > location, but that leads to its own complexity.
> >
> > I am confused. To make use of data it must be entered. I would suspect
> > that you would be required to have the xmitting location known regardless
> > of whether one used gnu tools or a rdbms.
>
> Yes, it must be entered.  However, my understanding of an RDBMS is that
> there can be a table of TX QTHs, for example, and then each QSO record
> contains the primary key of the TX QTH table so each QSO record is
> associated with one TX QTH.
>
> With the flat file format the key seems to be entering consistent string
> for each TX QTH so we can search it later with grep.  If Xlog would store
> the TX QTHs and offer it as a spinbox rather than a free-form field, then
> I think the functionality would be a toss-up between an RDBMS and the flat
> file.
>
> > Again, the question for you to answer -> Why consider this, to what end,
> > and please be specific.
>
> It was an idea.  I brought it up for Joop's consideration.  It is solely
> up to him to decide its merit.  I thought an embedded RDBMS might offer
> some speed and flexibility and offer a more-or-less standard way of
> working with the QSO data.  I also thought it might ease the development
> work of Xlog in the future as it would not need to concern itself with
> the things SQLite handles.
>
> As I am not well versed in the classic UNIX tools, I did not think in
> that direction.  I first thought of Perl to sort my log and then thought
> of a DB that could do that for me or the application that uses it.
>
> If I am way out in left field then teach me a better way.
>
> 73, de Nate >>

O.K. Nate;

Well we have talked this to death. Suffice it to say that there is nothing 
here that cannot be done within the current arrangements while using the Bash 
+ GNU tools. I also agree with the thought, as you stated in an earlier 
email, that keeping the current "flat" file format is best.

Um, I can make some suggestions on what to read up on if that would help your 
studies in this area, provided this is what you would desire.

(As to "easing the development of Xlog, alot of what you ask for can be 
accomplished without changing the file format AND without adding the "shell 
scripting" by adopting some widgets from one of the popular libs for such 
things. Then a quick "sort by category" can be done right on the screen, 
within Xlog. An example of this is the "field sort" in Kmail. There are 
*many* other such examples extent. Since this requires alot of work for Joop, 
I never brought it up, but it would do nicely for what you are asking for.)

Very best regards;

Bob
w9ya





reply via email to

[Prev in Thread] Current Thread [Next in Thread]