Variant array in a cached property.

[chris]

Hello,
Has anyone used a variant data type and array as one of the custom
properties being cached in indexing service. Can anyone give me a real world
example of someone doing this.

Lets say I had an htm page with 10 photo captions metatags, 500 characters
in each caption, being cached as 10 seperate custom metatag properties named
'caption1', 'caption2', 'caption3', etc. Would I be better off performance
wise to take all of those custom metatag properties, totalling 5000
characters per *.htm page, and putting them into a single custom property
that was an array so that I would have just one custom property named
'CAPTIONS'.

Is there any benefit in using an array with a variant type in this situation?

How do other people benefit from using a variant datatype an having a array
used as a custom property. What is the benefit? Is it a cosmetic benefit, a
performance benefit, or a display benefit?

I understand the benefits of an array with programming, but I can't really
see any benefit for the example I used above unless the benefit is to have
less properties. Your still going to have the same amount of data in the
properties cache in the long run.

However, instead of having 10 different metatag properties with the data
spread out evenly, you will have one giant property with all the data from
the 10 individual properties. Wouldn't you have some kind of performance hit
with a single property being a huge variant data property. How would the
querys performance be on the catalog? better or worse? Is there any
performance degradations in using a custom property as an array with a
variant datatype?

Thank you for your time,
Chris

[Lorin McCaffrey]

I've gotten half way through an implementation that uses arrays in a custom
property, but am now stuck. I had no problem getting data into the indexing
service as an array, but I am having trouble getting it back out.

My project is a bit different from yours and is not based on htm metatags.
In my case I wanted to use arrays because I don't know ahead of time how
many properties there would be in the collection (yours seems to be 10 all
of the time).

When the indexing service indexes my file (and gets an array as one of the
properties) it produces no errors. I can see the property in the property
list of the catalog. However, no matter how I query the index afterwards, I
cannot get a value for that property (if you get this far and can get the
array back in a query please let me know how!).

Although I'm no expert by far, I wouldn't worry about performance. Like you
said, the amount of data is the same no matter how you do it. I would argue
that splitting it up into multiple properties would slow things down, as you
have some overhead to set and get each property.

Post by chris
Hello,
Has anyone used a variant data type and array as one of the custom
properties being cached in indexing service. Can anyone give me a real world
example of someone doing this.
Lets say I had an htm page with 10 photo captions metatags, 500 characters
in each caption, being cached as 10 seperate custom metatag properties named
'caption1', 'caption2', 'caption3', etc. Would I be better off performance
wise to take all of those custom metatag properties, totalling 5000
characters per *.htm page, and putting them into a single custom property
that was an array so that I would have just one custom property named
'CAPTIONS'.
Is there any benefit in using an array with a variant type in this situation?
How do other people benefit from using a variant datatype an having a array
used as a custom property. What is the benefit? Is it a cosmetic benefit, a
performance benefit, or a display benefit?
I understand the benefits of an array with programming, but I can't really
see any benefit for the example I used above unless the benefit is to have
less properties. Your still going to have the same amount of data in the
properties cache in the long run.
However, instead of having 10 different metatag properties with the data
spread out evenly, you will have one giant property with all the data from
the 10 individual properties. Wouldn't you have some kind of performance hit
with a single property being a huge variant data property. How would the
querys performance be on the catalog? better or worse? Is there any
performance degradations in using a custom property as an array with a
variant datatype?
Thank you for your time,
Chris

[Dave Schile]

Lorin,
I have been succesful in returning custom properties in an array.
First, I must ask how you are using custom properties if you aren't using
meta tags to create them? How are you entering custom data in a document
without the use of metatags?

To return custom properties as an array:
Fist make sure that you cache the property in your catalog. Set the propery
datatype as a VT_VARIANT

When you are returning the properties (lets say you are using the
ixsso.query object in an asp page)

use the definecolumn method to let object know how to build the resulting
recordset:
oQuery.DefineColumn "capton(DBTYPE_WSTR|DBTYPE_BYREF) =
d1b5d3f0-c0b3-11cf-9a92-00a0c908dbf1 caption"

use the ixsso.util objects GetArrayElement method to itereate through the
array elements:

Set oRs = oQuery.CreateRecordSet("nonsequential")
for i=0 to ubound(oRs("caption"))
Response.Write(oUtil.GetArrayElement(oRs("caption"),i) & "<br>")
next

Let me know if this helps you.

Dave Schile

Post by Lorin McCaffrey
I've gotten half way through an implementation that uses arrays in a custom
property, but am now stuck. I had no problem getting data into the indexing
service as an array, but I am having trouble getting it back out.
My project is a bit different from yours and is not based on htm metatags.
In my case I wanted to use arrays because I don't know ahead of time how
many properties there would be in the collection (yours seems to be 10 all
of the time).
When the indexing service indexes my file (and gets an array as one of the
properties) it produces no errors. I can see the property in the property
list of the catalog. However, no matter how I query the index afterwards, I
cannot get a value for that property (if you get this far and can get the
array back in a query please let me know how!).
Although I'm no expert by far, I wouldn't worry about performance. Like you
said, the amount of data is the same no matter how you do it. I would argue
that splitting it up into multiple properties would slow things down, as you
have some overhead to set and get each property.

Post by chris
Hello,
Has anyone used a variant data type and array as one of the custom
properties being cached in indexing service. Can anyone give me a real world
example of someone doing this.
Lets say I had an htm page with 10 photo captions metatags, 500 characters
in each caption, being cached as 10 seperate custom metatag properties named
'caption1', 'caption2', 'caption3', etc. Would I be better off performance
wise to take all of those custom metatag properties, totalling 5000
characters per *.htm page, and putting them into a single custom property
that was an array so that I would have just one custom property named
'CAPTIONS'.
Is there any benefit in using an array with a variant type in this situation?
How do other people benefit from using a variant datatype an having a array
used as a custom property. What is the benefit? Is it a cosmetic benefit, a
performance benefit, or a display benefit?
I understand the benefits of an array with programming, but I can't really
see any benefit for the example I used above unless the benefit is to have
less properties. Your still going to have the same amount of data in the
properties cache in the long run.
However, instead of having 10 different metatag properties with the data
spread out evenly, you will have one giant property with all the data from
the 10 individual properties. Wouldn't you have some kind of performance hit
with a single property being a huge variant data property. How would the
querys performance be on the catalog? better or worse? Is there any
performance degradations in using a custom property as an array with a
variant datatype?
Thank you for your time,
Chris