Le 07/01/2014 13:22, Tomasz Sterna a écrit :
object-sequence is used mainly for sorting - to keep stanza ordering,
etc.
There is no enforcement on uniqueness, but in cases when you do care on
ordering, these should be unique.
In roster table you should be fine with just incrementing ver.
BTW, you could just write your UPDATE queries setting ver with next
sequence number for the table. It will save you incrementing in code and
keep it in line with how the original module does things.
I can have something like "UPDATE `roster-items` SET
`object-sequence`=`object-sequence`+1" but his break uniqueness in the
table. I haven't found any easy ways to do something similar with
LAST_INSERT_ID() or AUTO_INCREMENT in MySQL, hence my question. I think
I'll stick to that for now.
My bet is that loading user data for packet delivery causes that.
There is an old item on Rob's TODO list, to have two load-user events -
one when user logs in, and other used for delivery, which loads only
necessary user data. But it is still TODO
Ok thanks. If performances really become an issue for me, I may get the
time to look into that.
One of the reasons we have memory pools in jabberd2.
Just to check : you're talking about the pools in "pool.h". For the
record, group management in the roster do not seem to use them. If I'm
correct, every time an user changes groups, there are potential
mallocs/frees. Same goes for _roster_user_load. Maybe at one point it'll
be better to use pools for roster items too (item, item->name,
item->groups and its content). I've not yet profiled anything, but this
may be a way to improve speed when loading user data for packet delivery
(without having to code 2 load-user events).
Then again, I'll focus on the features I need for now. Perf issues will
come later.
--
Sylvain "Gugli" Guglielmi
