Re: [PATCH 06/12] space: space_vtab::build_secondary_key => build_index

[Vladimir Davydov <vdavydov.dev@gmail.com>]

On Mon, Apr 09, 2018 at 11:39:25PM +0300, Konstantin Osipov wrote:
> * Vladimir Davydov <vdavydov.dev@gmail.com> [18/04/09 10:33]:
> > -	space_build_secondary_key_xc(new_index_def->iid != 0 ?
> > -				     alter->new_space : alter->old_space,
> > -				     alter->new_space, new_index);
> > +	space_build_index_xc(new_index_def->iid != 0 ?
> > +			     alter->new_space : alter->old_space,
> > +			     new_index, alter->new_space->format);
> >  }
> 
> This is confusing, why do you ever need to pass the old space? 
> A new index should always be built in the new space, no?

We always build an index *for* the new space, but the 'space' argument
here denotes the space to use as the source for building the new index.
If we are rebuilding the primary key, we have to pass the old space,
because the new space is empty.

> 
> >  	/**
> > -	 * Called with the new empty secondary index.
> > -	 * Fill the new index with data from the primary
> > -	 * key of the space.
> > +	 * Build a new index, primary or secondary, and fill it
> > +	 * with tuples stored in the given space. The function is
> > +	 * supposed to assure that all tuples conform to the new
> > +	 * format.
> >  	 */
> > -	int (*build_secondary_key)(struct space *old_space,
> > -				   struct space *new_space,
> > -				   struct index *new_index);
> > +	int (*build_index)(struct space *space, struct index *index,
> > +			   struct tuple_format *format);
> 
> Not having parameter 'space' documented, and not having the
> relationship between 'space' and 'format' documented (why can't we 
> use space->format) doesn't provide more clarity either.

OK, I will update the comment.