Tim

Any reason why [FILTER TYPE COLUMN <ColumnName>] can't be a boolean? I have a column indicating wether the text is plain text (True) or html (False) and since its for emails I don't see a need for anything else which is why its boolean not varchar.

Also its allows a memo field to be selected for [FILTER TYPE COLUMN <ColumnName>] - duh???


Roy Lambert

Roy,

<< Any reason why [FILTER TYPE COLUMN <ColumnName>] can't be a boolean? >>

It has to be a CHAR or VARCHAR column to indicate the type of data that is
stored in the indexed column.  This value is passed to the text filter so
that it can determine what to do with the text.

<< I have a column indicating wether the text is plain text (True) or html
(False) and since its for emails I don't see a need for anything else which
is why its boolean not varchar. >>

Just use a VARCHAR with 'Plain' and 'HTML' as the values.  Or you could even
use standard encoding phrases such as 'text/plain' or 'text/html'.

<< Also its allows a memo field to be selected for [FILTER TYPE COLUMN
<ColumnName>] - duh??? >>

A CLOB column is just a long string, which means that it is compatible to be
used as a filter column.

--
Tim Young
Elevate Software
www.elevatesoft.com

Tim

><< Any reason why [FILTER TYPE COLUMN <ColumnName>] can't be a boolean? >>
>
>It has to be a CHAR or VARCHAR column to indicate the type of data that is
>stored in the indexed column. This value is passed to the text filter so
>that it can determine what to do with the text.

Hmmm - I'm going to find my Tim voodoo doll for that. Booleans work for plain/formatted (ok they can't differentiate which type of formatted) but integers could.

>A CLOB column is just a long string, which means that it is compatible to be
>used as a filter column.

Compatible yes, and I could probably make a case where it could be used, but my own preference would be to disallow it.

Roy Lambert

Roy,

<< Hmmm - I'm going to find my Tim voodoo doll for that. >>

That must be one extremely handsome voodoo doll.

<< Booleans work for plain/formatted (ok they can't differentiate which type
of formatted) but integers could. >>

Yes, but only strings provide the most versatility.

<< Compatible yes, and I could probably make a case where it could be used,
but my own preference would be to disallow it. >>

Take a case like our newsgroup articles table.  The headers are stored
separate from the body, and the headers contain the encoding of the body,
among other things.  Both are stored in memo (CLOB) columns.  This means
that the headers can be passed to the text filter and it can parse them out
and determine the body encoding and how to filter it.  No extra columns are
required.

--
Tim Young
Elevate Software
www.elevatesoft.com

Tim


>That must be one extremely handsome voodoo doll.

OK I find myself roundly beaten there!

>
><< Booleans work for plain/formatted (ok they can't differentiate which type
>of formatted) but integers could. >>
>
>Yes, but only strings provide the most versatility.

There are more numbers than there are characters or permutations of them (mind you I have yet to see a database that's capable of handling Cantorian numbers

>Take a case like our newsgroup articles table. The headers are stored
>separate from the body, and the headers contain the encoding of the body,
>among other things. Both are stored in memo (CLOB) columns. This means
>that the headers can be passed to the text filter and it can parse them out
>and determine the body encoding and how to filter it. No extra columns are
>required.

I presume these are custom headers cos I don't remember any RFC talking about storing message format in the headers. At best you might have an indicator that they're mime encoded.

However, that raises an interesting performance point. The overhead on parsing each header to decide how to manipulate the message for indexing must be quite high.

But enough of this back to your work - you only have 10 days before the release date!

Roy Lambert

Roy,

<< I presume these are custom headers cos I don't remember any RFC talking
about storing message format in the headers. At best you might have an
indicator that they're mime encoded. >>

That's exactly what I was referring to.  You could have HTML, plain text,
embedded images, etc. that all need to be filtered, stripped-out, etc.

<< However, that raises an interesting performance point. The overhead on
parsing each header to decide how to manipulate the message for indexing
must be quite high. >>

Nah, not at all.  It only has to be done once per indexing operation and
only when the indexed CHAR, VARCHAR, or CLOB column is actually modified.

<< But enough of this back to your work - you only have 10 days before the
release date! >>

Yeah, thanks for reminding me about that.

--
Tim Young
Elevate Software
www.elevatesoft.com