BOOLEAN conversion

Issue #173 resolved
Thomas Waldmann
created an issue

I am not sure whether this is a bug or just wrong expectations.

If you declare a BOOLEAN field and give it True/False at indexing time, everything's fine.

In case you give it e.g. "true" or "false" or "1" or "0" ... (the same values as you could use at query time), all of them get indexed like True (because bool(str) is True if str is not empty).

So this is basically an API question. What shall the API take? Just the specific type or also text with "meaning"?

This question also applies to the pull request I made today, it is basically same thing for DATETIME.

Comments (7)

  1. Matt Chaput repo owner
    • changed status to open

    The current API was written with the idea that you would pass an actual bool/datetime/whatever object.

    It does seem a bit inconsistent with parsing... I could apply the field's "self parsing" code when indexing.

  2. Matt Chaput repo owner

    Currently, after you allow e.g. date="20011031" in addition to date=datetime(2001, 10, 31), the way the code currently works, if the field is stored, you'll get "20011031" as the stored value, instead of a datetime object as one (or at least I) would expect. I'll have to move the conversion up to a higher layer.

  3. Chris Wilson

    Hi Matt,

    I think this is causing incompatibility between newer versions of Whoosh, and Haystack's Whoosh backend, which apparently expects to pass the strings "true" and "false" to Whoosh for BOOLEAN columns.

    I've reported this issue in Haystack as well, with a patch to pass bool values instead:

    Can you give us an idea of when this changed in Whoosh, so we'd know what the backwards compatibility implications would be in changing it?

    Also, the truthy values currently don't include True and False, which are the stringifications of the Python values. This is what you currently get if you use Haystack's SearchQuerySet to search for (deleted=True) for example: sqs.exclude(deleted=True) results in the value 'True' is passed to BOOLEAN.parse_query, which decides that you really meant False! Would it make sense to add them? I'm looking at fixing this better in Haystack as well.

    Cheers, Chris.

  4. Chris Wilson

    Hi Matt,

    Thanks for adding support for strings as well!

    Do you remember when the design changed to expect bool values instead of strings?

    About the parse_query issue, you're right. My copy of 2.3.2 has this:

        def to_text(self, bit):
            if isinstance(bit, string_type):
                bit = bit in self.trues

    which is case sensitive, but I guess you must have fixed that in a more recent version.

    Cheers, Chris.

  5. Log in to comment