On Tue, May 26, 2015 at 05:26:06PM +0200, Pavel Březina wrote:
On 05/26/2015 05:22 PM, Jakub Hrozek wrote:
>On Thu, May 21, 2015 at 11:44:08AM +0200, Pavel Březina wrote:
>>https://fedorahosted.org/sssd/ticket/2338
>>
>>Depends on IFP: users and groups
>
>I haven't tested the code yet at all, but let's start the review :-)
>
>> From b08f37a1bf9593c74cdec8d829f0d125b9c66c30 Mon Sep 17 00:00:00 2001
>>From: =?UTF-8?q?Pavel=20B=C5=99ezina?= <pbrezina(a)redhat.com>
>>Date: Mon, 18 May 2015 12:05:38 +0200
>>Subject: [PATCH 1/4] IFP: Implement
>> org.freedesktop.sssd.infopipe.Cache[.Object]
>
>This patch need to be split into one that just adds the functionality
>and one that adds the sysdb upgrade.
>
>But mostly, I'm not sure we need to index this attribute, do you think
>the lookups for cached objects would be so frequent? Keep in mind that
>indexing adds some penalty on the cache size but also building the
>indexes is not totally for free, so we should carefully consider the
>indexes..
>
>Additionally, we were talking with Sumit about sysdb upgrades for
>indexing attributes with the context being:
>
https://fedorahosted.org/sssd/ticket/2597
>
>What Sumit proposed to investigate if we could get away of not bumping
>the version (or adding a .z version to the sysdb string) if all we
>change is indexes..do you have time to test that? (newer indexes with
>older client etc..)
>
>I would prefer a different name for the new attribute, cache is too generic,
>can we prefix the name?
All of the above was agreed on the design page. I don't oppose to removing
the index nor renaming the attribute, can we discuss it in the design
thread? We can add index sometime later if we notice it is a bottleneck, no
problem there.
Sure. Discussing if the cache upgrade is needed at all might be even
better in a separate thread. Sorry if it was discussed, I forgot that...
I'm not too opposed to adding the index. In LDB, it's another record in
the form of:
indexed_attribute:DN
Plus every time a cached attribute is modified, added or deleted, this
index record must be changed accordingly as well.
Please note the indexing itself is not the problem, I would just like
to avoid two sysdb upgrades if we can and avoid the upgrade at all, even
better.