[ewiki] Re: Use of EWIKI_DB_F_APPENDONLY

> If your issue was about preventing thread pages to get clicked independent
> from
> the pages they're attached to I would rather recommend using _F_DISABLED
> or _F_BINARY eventually even _F_SYSTEM or unsetting _F_TEXT.

I don't mind them being clicked, my problem is that I need to make lists of
just the thread pages for an aview plugin.

> But for the distinguishing purpose, you're right, there should be a better
> solution.
> If it wasn't sometimes that large I'd say we could let SEARCH and GETALL
> return
> the {meta} besides the {flags}. Eventually we should even add support for
> SEARCHing in multiple database fields (but that's complicated and far
> away...)
> 
> Right now I could only suggest using the $dbquery_result->get("_ALL")
> trick to
> fetch the whole database entry together with the SEARCH results.
>
> If you think the regex doesn't distinct the thread pages not exactly
> enough from
> other stuff in the database, so this was important enough, you could of
> course
> invent your own EWIKI_DB_F_CONSTANT. We then only needed to negotiate on
> the bit range (I hereby reserve all prime number bits for myself ;)
> I don't think "user flag values" is the best thing to do here, but as
> temporary
> workaround it would be ok?
 
I have two options for coding this up:

1.  Call a regex on each id returned by a SEARCH call to filter it down to
only thread pages.  This would look like
!"/".pagename."_THREAD_(.*)_POST\d\d\d/" if I could avoid this I would for
speed reasons.  
2.  Use a flag to filter in an equivalent way.

The flag would be a fine permanent solution to my mind.  The regex seems
like too much of a workaround to be left permanently. 

Andy

Other related posts: