[sr-dev] [ openser-Bugs-2824350 ] Presence DB support completely broken

SourceForge.net noreply at sourceforge.net
Tue Nov 10 17:14:09 CET 2009

Bugs item #2824350, was opened at 2009-07-20 17:49
Message generated for change (Settings changed) made by axlh
You can respond by visiting: 

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: modules
Group: ver 1.5.x
>Status: Closed
>Resolution: Fixed
Priority: 5
Private: No
Submitted By: Alex Hermann (axlh)
Assigned to: Nobody/Anonymous (nobody)
Summary: Presence DB support completely broken

Initial Comment:
As subject.

commit 5840 did the damage


>Comment By: Alex Hermann (axlh)
Date: 2009-11-10 17:14

Yes, as far as I remember it is fixed.


Comment By: Daniel-Constantin Mierla (miconda)
Date: 2009-10-05 09:07

IIRC, this was fixed, so item can be closed, right?


Comment By: Alex Hermann (axlh)
Date: 2009-07-24 14:43

I agree that choice is better, but it requires a major rewrite. Maybe a
common library can be created for all modules using DB and cache. Maybe
even throw in a memcached cache as a choice. And prepared statements in
case the DB is used during runtime.....

Just missing my favorite mode: 
=4: cache only at runtime, DB save/restore at shutdown/init time.


Comment By: Klaus Darilion (klaus_darilion)
Date: 2009-07-21 15:43

What about having a new parameter like userloc?

=0: no DB
=1: read from cache, write/update to cache and DB
=2: read from cache, write to cache and delayed write/update to DB
=3: db_only, no cache


Comment By: Nobody/Anonymous (nobody)
Date: 2009-07-21 14:00

Patch is ok, cleaner with new parameter rather than playing with falback2db
value. I will apply it.

Updating on timer is good for the cases of sudden crash, maybe a new mode
to skip timer updates and store only at shutdown is more appropriate.


Comment By: Alex Hermann (axlh)
Date: 2009-07-21 13:11

I decided to dive into the code some more. It's a bit messy. There are 2
modes of operation determined by fallback2db. Both modes don't work
correctly, the documentation for the modes contradict the code it
contradicts ITSELF. So the first thing to do to fix this is to get the
desired behavior for both modes documented.

More information about the sr-dev mailing list