[IRCServices Coding] get_nickinfo like functions suggestion

Andrew Church achurch at achurch.org
Wed Jun 25 10:35:53 PDT 2003

     Easy counterexample: /os akill add luser@*.example.com (where it
would definitely _not_ be proper to use out-of-date data)

  --Andrew Church
    achurch at achurch.org

>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 
>for more efficient caching of data. The reasoning behind this is that 
>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 
>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 
>that either the data in the database would be locked for too long and no 
>program could ever modify it, or if we didn't lock the entries in the 
>we would end up overwriting any changes another program made once we 
>the cache.
>So basically I propose creating database functions using names like 
>or get_readonly_chaninfo, which would be used by commands such as INFO, 
>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 
>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 
>readonly/cache functions to conditionally modify other data (example, you 
>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 
>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 
>If I seem to be spouting gibberish, by all means ask me to clarify.
>To unsubscribe or change your subscription options, visit: