On Thu, Mar 22, 2012 at 6:38 PM, <[email protected]> wrote: > On Thu, Mar 22, 2012 at 05:28:50PM +0100, Emmanuel Lécharny wrote: > > Le 3/22/12 5:11 PM, [email protected] 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
