[RFC PATCH 11/23] xrow: allow to store flags in DML requests

Vladimir Davydov vdavydov.dev at gmail.com
Wed Aug 1 17:10:57 MSK 2018


On Tue, Jul 31, 2018 at 11:36:34PM +0300, Konstantin Osipov wrote:
> * Vladimir Davydov <vdavydov.dev at gmail.com> [18/07/08 22:52]:
> > In the scope of #2129 we need to mark REPLACE statements for which we
> > generated DELETE in secondary indexes so that we don't generate DELETE
> > again on compaction. We also need to mark DELETE statements that were
> > generated on compaction so that we can skip them on SELECT.
> > 
> > Let's add flags field to struct vy_stmt. Flags are stored both in memory
> > and on disk so to encode/decode them we also need to add a new iproto
> > key (IPROTO_FLAGS) and the corresponding field to struct request.
> 
> We have been avoiding IPROTO_FLAGS so far. Can we make this
> member engine-local, i.e. make sure it's only visible/usable for vinyl rows?

The problem is vinyl uses the same format (and functions) for
encoding/decoding statements that are used by xlog, e.g. decoding is
done by xrow_decode_dml via struct request. So I don't see any other
way to introduce per statement flags rather than adding a new field
to struct request and making xrow_decode_dml aware of it...

I agree that IPROTO_FLAGS looks too generic though. We can rename it to
IPROTO_TUPLE_FLAGS to avoid confusion.

Alternatively, we could rename it to IPROTO_VY_STMT_FLAGS (and
request::flags to request::vy_stmt_flags) to emphasize that it is only
relevant for vinyl, but we would still have to add handling of this
flag in the generic code (xrow_encode/decode_dml). This would look ugly
IMO.

What do you think?



More information about the Tarantool-patches mailing list