[IRCServices Coding] get_nickinfo like functions suggestion

Finny Merrill griever at t2n.org
Tue Jun 24 14:59:10 PDT 2003


After discussing mysql module design it occurred to me that it would make 
designing a
caching database module for mysql much easier if the get_ functions had 
analogs for
read-only use.

I figure that if we create functions like get_readonly_nickinfo, it would 
allow
for more efficient caching of data. The reasoning behind this is that 
procedures
which modify a nick/channel/nickgroup need to have a more updated version 
of the
data in order to figure out whether it can be modified the way it wants to.

On the other hand, many functions that only read from these pieces of data
would not have to have the most recent version and could use the cached 
version
since it would cause little harm to simply display out-of-date information
to the user.

If we cached all pieces of data (including read-write), then it would 
happen
that either the data in the database would be locked for too long and no 
outside
program could ever modify it, or if we didn't lock the entries in the 
database,
we would end up overwriting any changes another program made once we 
invalidated
the cache.

So basically I propose creating database functions using names like 
get_readonly_nickinfo
or get_readonly_chaninfo, which would be used by commands such as INFO, 
ACCESS LIST,
AKICK LIST, AKILL LIST, and for determining access etc. The regular 
get_nickinfo etc
functions would retain the same functionality for backwards compatibility 
and nothing
would break.

These new get_readonly_* (or if you want, get_cache_*) would be implemented 
in modules
that cache nick information in memory. In modules where either a) 
information is ALWAYS
read from database on get_* or b) all information is always in memory, they 
would be
synonyms for the regular get_* functions (i.e. in version4, they would be 
synonyms).

The info returned by these functions would generally not be modified (save 
for things
that aren't saved to database such as the locked field) and wouldn't be 
passed to
put_* functions. Also, it would be a bad idea to use the info returned from 
the
readonly/cache functions to conditionally modify other data (example, you 
wouldn't
use these functions to check someone's access so that they could change 
channel options,
since another program could recently have removed them from the access list 
without
us knowing it. It would be safe however to check someone's access to join 
the channel,
use INVITE UNBAN OP etc, because that doesn't involve changing the 
ChannelInfo).

If I seem to be spouting gibberish, by all means ask me to clarify.