Skip to main content.
home | support | download

Back to List Archive

Change in way undefined properties are handled

From: Bill Moseley <moseley(at)not-real.hank.org>
Date: Tue Jan 13 2004 - 17:48:14 GMT
Here's just a heads-up on a change to swish.

I'm trying to clean up the way undefined properties are handled.
Actually, there's two problems.  It will result in a change in
behavior.

This is a result of a thread last week about formatting dates.

I'm also interested in feedback from any Perl (SWISH::API) users.

First problem:  the "(NULL)"

There's two ways to list properties -p and -x.  If a property is not
defined for an index there's these two responses:

    $ swish-e -w not dkdk -p badpropname -H0
    err: Unknown Display property name "badpropname"

    $ swish-e -w not dkdk -x '<badpropname>\n' -H0
    (NULL)

That (NULL) is often seen when using swish.cgi's default settings (which
uses the swishdescription property) but the index was not created with
StoreDescription.

My plan is to make them both cause an error (like the first one).  The
only downside is with the second method you can search two indexes at
the same time that do not have the same property list and not get an
error.

For the C API the caller will be expected to check for errors after the
call, but the program will not abort.  This is similar to the current
behavior, although currently no error is returned other than a NULL
(which indicates an invalid property name).

For the SWISH::API module, which currently just returns the undefined
value, I think the correct thing to do is croak() -- which is what the
binary would do.

That change to SWISH::API could cause some existing uses to break,
although croak()ing will produce a better message than that "(NULL)"
string.


Second Problem:  Undefined property values

Here's where the current design is really broken, but fixing it will
likely cause problems (when using SWISH::API).

Currently, if you ask to display a property, but a given file doesn't
contain that property, an empty string is returned.  That's even the
case for properties that are dates and numbers.  Normally, this works
fine for the swish-e binary because all properties are returned as
strings.  Where it breaks with the binary is when using formatting
strings.

Anyway, for the swish-e binary it will still return a blank string (but
with fixing the fmt problem shown below).  For the Library calls an
undefined string will also return NULL.  To tell the difference in the
library between an invalid property name and just an undefined value you
will need to call the SwishError() function.

For the SWISH::API module, undefined values will return undefined.
I'll have to update swish.cgi to not generate warnings
when trying to print undefined values.


More details than you probably want, but here's an example of the format
string problem:

    $ cat c
    PropertynamesDate foo

    $ swish-e -i c -c c -v0

    $ swish-e -w not dkd -H0 -p swishlastmodified
    1000 c "c" 23 "2004-01-13 09:08:45"

    $ swish-e -w not dkd -H0 -x '<swishlastmodified fmt="%d %B %Y">\n'
    13 January 2004

But if you use a property name that is undefined:

    $ swish-e -w not dkd -H0 -x '<foo fmt="%d %B %Y">\n'
    1075353525 %B %Y

That's because the undefined property got turned into a STRING type of
value, but fprint() is still using the same format string.





-- 
Bill Moseley
moseley@hank.org
Received on Tue Jan 13 17:48:34 2004