On Thu, Mar 22, 2012 at 6:38 PM, <hyc@symas.com> wrote:
On Thu, Mar 22, 2012 at 05:28:50PM +0100, Emmanuel Lécharny wrote:
> Le 3/22/12 5:11 PM, hyc@symas.com a écrit :
> >On Thu, Mar 22, 2012 at 04:40:17PM +0100, Emmanuel Lécharny wrote

> >>Now, if we consider the fact that having all the AT stored in the
> >>index will allow us to know what will be the impacted entries if an
> >>AT is removed from the schema, then it can be a good thing to have a
> >>complete index with all the AT.
> >It's an interesting idea, if the admin was going to index it anyway.
> >Otherwise, IMO you're optimizing for a very infrequent case, which
> >is self-defeating.
> Here, it's not about optimization, really.
> The idea is much more about bieng able to see if an AT removal from
> the schema is likely to impact the data, without doing a full scan.

Yes... but "avoiding a full scan" is just a (coarse) optimization of
the schema change.

> Not sure it's a sane politic though : removing an AT from a
> production server sounds a bad idea...

Agreed. And again, even if it's for a valid reason, it will occur once
in a blue moon. Who cares how long it takes?

If you're really concerned about this scenario, sounds like a refcount
on the schema elements would be more straightforward.

+1 this would be easier to comprehend and maintain in the long run verses this mechanism which couples the index to ref-count like functionality.

Best Regards,
-- Alex