On Fri, 2012-11-02 at 09:14 -0700, Travis Reitter wrote:
On Fri, 2012-11-02 at 09:52 +0100, Xavier Claessens wrote:Le jeudi 01 novembre 2012 à 14:24 -0700, Travis Reitter a écrit :On Thu, 2012-11-01 at 21:19 +0000, Philip Withnall wrote:Are you thinking of Tpf.Persona.dup_for_contact()? It takes a TpContact and spits out a Tpf.Persona. From the Tpf.Persona, you can get a Folks.Individual from its ‘individual’ property.No, I meant a general any Persona -> their Individual. It's also possible that it was something like Persona.uid -> their Individual.Afaik you can do that only if you loaded the full aggregator. Which is IMHO not something we want to do in half a dozen processes.Right. That would be true in any case though - even if we cached all the links in some special DB (it would just load much more quickly).
Agreed.
Maybe a link cache is one of the things we need. In the common case, any
*snip* All sounds pretty similar to thoughts I’ve had. A cache should speed initial aggregation up, but it can imagine lots of corner-case bugs where the cache gets into a stale state.
Even farther in the future, we might be able to come up with a heuristic that lets us refresh the Individuals (and their Personas) who are most likely to have changed since we last wrote out the cache. I can hear Philip cringing audibly already.
I think that kind of work should only be done after all the low-hanging fruit has been picked by the cache, and then after a lot more profiling work. Philip
Attachment:
signature.asc
Description: This is a digitally signed message part