RE: [NeoStats-Devel] SeenServ

> 
> it currently does hold the entire db in memory, I had a look 
> through the DBA
> stuff in the core, but couldn't find anything that could read 
> through in
> order, or have multiple keys for searching. currently the 
> records are stored
> with the nick being used as the key. when new events occur.
> 

Without seeing the code, its hard to suggest a option. Anyway, you can check
it in now at http://svn.neostats.net/svn/SeenServ/trunk :)


> if the nick has an event in the list already, it removes the 
> old event for
> the nick before appending the new one, thus keeping the list 
> in time order
> always and not duplicating nicks. so far since I added the 
> saving to the
> database earlier today, it has seen around 5000 events, but 
> only had 37
> entries in it's list due to the same nicks causing the events.
> 
> adding a timed expiry should be real easy as the times are 
> kept on each
> record. with an option to use record count or time, or both.
> 
> having it work completely from a file instead of memory is 
> another story,
> and will probably need help with that one to have any chance 
> of getting it
> right with my level of knowledge at the moment :)
> 

Right now, are you using a list or a hash? Using a list means that you have
to search through all the records one by one till you get a match. As the
records get large, this could cause performance problems. If you use a hash,
and use the nick as the key, you can pretty much directly retrive the record
without having to write compare functions etc.

The database is just as simple (I think, without seeing the code again, I'm
just guessing...) but if your storing using the nickname as the database key
when you save, you could just to a DBGET command to retrive the seen info
for that nick. If it return NULL, then it doesn't exist and you tell the
user so, if it does exist, well, you only need to keep it around in memory
for the request, and then can drop it later... (but, for performance
reasons, you might want to have all *online* users loaded in memory, and use
your incremental saves to update the DB with changes... This avoids having
to do DB calls on all entries... Then when a user issues a !seen command,
you first check the "online" hash, and if its not there, issue a DB call,
and if you don't get anything tell something witty to the user. :)

Justin