[pmwiki-users] smarter PageStore::ls() parameters?

[Patrick R. Michaud]

On Mon, Oct 16, 2006 at 02:18:11PM -0700, Martin Fick wrote:
> --- "Patrick R. Michaud" <pmichaud at pobox.com> wrote:
> > Assuming you mean "page attribute" in the way that I
> > use the  term -- i.e., a key/value pair that is 
> > stored in the individual page files -- 
> 
> Yes, we are speaking apples to apples.
> 
> > then this doesn't seem to be at all helpful.  Very 
> > few of the arguments that we give to (:pagelist:) 
> > have an exact or meaningful correspondence directly 
> > to a page attribute.  In fact, with the possible
> > exception of text= , all of the ones that would have
> > such a mapping are already being handled by the 
> > present system.
> 
> This could be where I am way off, but I was thinking
> that the targets= attribute would be very important
> for many pagelists (Categories).  If storing pages in
> a DB, it seems like categories should be optimized
> with the DB, instead of the pageindex.

Yes, but you also said (earlier):

> > > Select($namepats, $attpats)
> > > 
> > > where $namepats is equivalent to what the current
> > > $pats is for ls() and the $attpats is an array indexed 
> > > by attribute which contains an array of patterns to 
> > > match for that specific page attribute (which could
> > > include the page text).  

and I'm interpreting "array of patterns" to essentially
mean "array of regex".  Do many databases allow filtering 
of records based on regexes?

> Would not a page text variable {$:var} search also be
> able to take advantage of this?

Maybe -- but only if the PageStore makes some big assumptions
about the way that page variables are stored.  Currently
page text variables are a customizable feature (via the 
$PageTextVarPatterns[] array), and I think it would be 
pretty difficult to go from $PageTextVarPatterns[] to a 
specific set of "text patterns" that would be a criteria
for searching.

As an example, how would one get from 
(:pagelist $:Author=A*,B*:) to an optimized search of the pages, 
given that we only have $PageTextVarPatterns[] that are
really intended to go from markup text to variable and
not vice-versa?

> I can't help but think that there are other attributes
> that people filter (or would like to filter) on?  Last
> update time, last author, title?  

Sure, but for these we (currently) use $LastModified, 
$LastModifiedBy, and $Title in (:pagelist:), not time=, 
author=, and title=.   I'm not saying it wouldn't be
possible to add specialized filters for these that would
work with $attpats, but it's not the way we currently do
it and to some extent PmWikiPhilosophy #3 applies.

Also, time= isn't something easily matched by "an array of
patterns", so for that sort of filtering PageStore::select() 
would have to be interpreting some sort of irregular structure 
in $attpats.  If it's an irregular structure anyway, then
we might as well have PageStore::select interpret the
arguments directly for (:pagelist:).

But lastly, I'll note that I think my proposal likely subsumes
yours, since it would be fairly easy to have the $options
parameter include a computed "attrpat" entry for the
things that (:pagelist:) is able to figure out.  For example,

    function select($namepats, $options) { ... }

where $options['=attrpats'] is equivalent to the $attrpats
argument you mention above.  Then PageStore::select()
can do its things based solely on the attrpats, or based on
the other information provided in the pagelist arguments,
or both.

Indeed, as it currently exists, the $opts array in
MakePageList already has the computed patterns available
for the various filters it calls:

    $opt['=inclp']              terms required to be in text
    $opt['=exclp']              terms required to not be in text
    $opt['=pnfilter']           regexes of pagenames to match (i.e.,
                                the $namepats argument)
    $opt['=linkp']              required patterns for target=

I wouldn't have much of an issue with generalizing these to 
instead be

    $opt['=attrpats']['text']
    $opt['=attrpats']['targets']

to make it easier for a PageStore to apply these optimizations.
But my caveats about the difficulty of coming up with a good
pattern specification that works across attributes still
applies.

Pm