On Fri, Jul 22, 2022 at 11:11 AM Amit Kapila <amit.kapila16@gmail.com> wrote:
>
> On Fri, Jul 22, 2022 at 3:47 AM Peter Smith <smithpb2250@gmail.com> wrote:
> >
> > I was in favour of enum mostly because I thought the bitmask of an
> > earlier patch was mis-used; IMO each bit should only be for
> > representing something as "on/set". So a bit for
> > SUBSCRIPTION_REL_STATE_READY makes sense, but a bit for
> > SUBSCRIPTION_REL_STATE_NOT_READY seemed strange/backwards to me. YMMV.
> >
> > So using a bitmask is fine, except I thought it should be implemented
> > so that one of the bits is for a "NOT" modifier (IIUC this is kind of
> > similar to what Michael [1] suggested above?). So "Not READY" would be
> > (SUBSCRIPTION_REL_STATE_MOD_NOT | SUBSCRIPTION_REL_STATE_READY)
> >
>
> Hmm, I think that sounds more complicated than what I expected. I
> suggest let's go with a simple idea of using a boolean not_ready which
> will decide whether to use the additional key to search. I feel we can
> extend it by using a bitmask or enum when we have a clear need for
> more states.
Thanks for the comments, i have modified it by changing it to a
boolean parameter. The attached v4 patch has the changes for the same.
Regards,
Vignesh