Gossamer Forum
Home : Products : Gossamer Links : Version 1.x :

Keyword Tracker and SQL

Quote Reply
Keyword Tracker and SQL
Hi, can the Keyword Tracker also be used with links SQL? If so how do i get it working.
Quote Reply
Re: Keyword Tracker and SQL In reply to
There's no reason it shouldn't work. It doesn't use the links.db file at all, only picks up the search term and sends it to &search_log (or something).

The modification should be the same, allowing for the differences in the calling convention.

I would hope that Alex would consider adding this as a built-in feature of LinkSQL that could be turned on/off and uses an SQL table, since it would improve performce dramatically, and would only require a few additional lines of code, and a table set-up routine.

Scott


Quote Reply
Re: Keyword Tracker and SQL In reply to
I'm sorry' but the keyword tracker is realy not working with links SQL. can someone help me with is.
Quote Reply
Re: Keyword Tracker and SQL In reply to
What's not working?

LinkSQL uses a different variable to pass the search term -- check the form output. I believe it's:

name="query"

That means that is the variable you pass to the logger. Because the code doesn't interact with the links database, you can use the same code to open/close files as you do with links 2.0, but you need to set up the variables using the LinkSQL definitions, or pass absolute paths to the subroutine (this is easier).

Granted, I haven't installed this, since I'm just using my server logs for this, but if you can show the error message, or what isn't working, I can probably make it work very simply.

It's a real 'plug in' and all you have to do is pass the 'query' term to &log_search before leaving the search routine.



Quote Reply
Re: Keyword Tracker and SQL In reply to
Hi pugdog,

Could you please show me the codes you have placed in the search.cgi and Links.pm, so i can try it.

Tanks,
Jan-Willem
Quote Reply
Re: Keyword Tracker and SQL In reply to
Hi,

I haven't installed this in linkSQL, because the Server log gives me better data for my needs. It really _is_ a standalone program for Links, I'm not sure where you are having trouble. You add the subroutine to the end of the search.cgi (since that is where it will be called) and you add the &log_search($query) or whatever the variable name is at the end of the look-up. I don't know why you are mucking with any other files!

One of the requests here to Alex has been moving the keyword tracker to an SQL table. There are many things that could be done at that point.

Alex promised (fingers crossed) a new release of LinkSQL today, and I really hope it comes. I've been holding off a lot of things for next version (I never like to go into production with a new product's first version).

If there is no keyword tracker set up in it, then I will make my first "learn SQL" project the installation of one. (It should be a trivial amount of code... since SQL actually does all the work in this).

Is that fair??

With the current keyword tracker, you are still using flat-file databases, and that defeats the purpose of moving to SQL.... It will also get rid of any file-locking problems, since SQL does internal record-level file-locking.

Quote Reply
Re: Keyword Tracker and SQL In reply to
With version 1.02 out, I sat down to figure out the rules of the road, so to speak. Keyword logging should be just a simple subroutine call:

if exists 'keyword' increment count,
otherwise, add new record
return

Well.... it was all that and more <G>

The table I used is very simple:

Code:
#
# Host: localhost Database : links
# --------------------------------------------------------

#
# Table structure for table 'Search_Log'
#

CREATE TABLE Search_Log (
ID int(10) unsigned DEFAULT '0' NOT NULL auto_increment,
Term char(25) NOT NULL,
Count int(11) DEFAULT '0' NOT NULL,
Last_Look bigint(21) DEFAULT '0' NOT NULL,
PRIMARY KEY (ID),
UNIQUE Term (Term)
);

The above code will actually create the database table if used in the SQL command box. You can change the table name, but "Search_Log" was pretty intuitive.

The Search_Log.def file is:

Code:
# Auto Generated Config File.
# Created on: Mon Aug 23 21:52:54 1999
#

package Links: Smile
foreach $hit_arr(@$hits){
my $hit_hash =$db_table->array_to_hash($hit_arr); ## convert array to hash
$hit_hash->{'Count'} = $hit_hash->{'Count'} + 1; ## increment _Count_ field
$db_table->modify_record($hit_hash); ## send hash to _modify_
}
} else { ## more than one record found
## database contained multiple matches... error
print "Hit my only error condition found";
&site_html_search_failure ({ error => "More than one exact database match.", %in }) and return;
} ## if_elseif

} ## log_search

No utilties yet, but this does the job...
I'm sure it could be done in fewer lines, and with neater calls, but this explains the logic, at least. The kludge is that I still had not figured out all the calls, so I just used Alex's boilerplate.

---

BTW: Alex... smiley's are cute, but they affect the programming -- BSQL becomes {confused smiley}BSQL


[This message has been edited by pugdog (edited August 23, 1999).]
Quote Reply
Re: Keyword Tracker and SQL In reply to
[offtopic]

That's UBB's fault, not Alex's. I've always preferred wwwthreads over UBB, for many reasons, this being another (poor coding).

They should have the regex looking for strings to convert into the smilies make sure it checks for whitespace around it too, so that : BSQL for example wouldn't be touched.


------------------
Mark Waterous mark@projectlinux.org
Project Linux - www.projectlinux.org/

Quote Reply
Re: Keyword Tracker and SQL In reply to
This really shows that I need to allow keys to be non numeric, not auto increments as then the code becomes much cleaner:

my $query = shift;
my $db = new Links: BSQL '/path/to/def/Search_Log.def'
my $record = $db->get_record ($query, 'HASH');

if ($record) {
$record->{Count}++;
$db->modify_record ($record);
}
else {
$db->add_record ( { Term => $query, Count => 1, Last_Look => time() } );
}

Which is much simpler. I'll look at modifying DBSQL.pm so it can work like this this week.

Cheers,

Alex
Quote Reply
Re: Keyword Tracker and SQL In reply to
1) -- I know it's UBB's fault, but you can turn smiley's off, can't you?

2)
Quote:
This really shows that I need to allow keys to be non numeric, not auto increments as then the code becomes much cleaner:

Awesome idea Smile

BTW: Told you the search logger could be done in about 5 lines of code <G> I'm liking having installed MySQL more and more Smile