What are the guidelines for using FVAs vs. Computed Fields?

[smccoy]

Per the recommendations of experts, we have switched some of our FVA fields to Computed Fields that use the getFieldValue() function. With queries, the performance is significantly slower using the Computed Fields vs. FVA; and by significant the performce changes from almost instant with FVAs to 10's of seconds for the Computed Fields.

What are the guidelines for using Computed Fields and getting as much performance as possible?

[smccoy]

Anyone? Do I need to escalate this into a case number?

[LLawton]

I have never heard of replacing FVAs with computed fields as you describe, so I would really love to know what your experts had to say. Can you elaborate please?
An FVA works from a straight relationship to an item (think "join"), whereas the computed field has to go get the item you require by field value (think "query"). So it makes sense that performance is worse. What type of fields are you querying?

I think that either you stay away from querying on such fields, or you go back to FVAs.

[smccoy]

Hi.

Thank you for you reply.

We are attempting to pull in fields from the segment item when in the context of a node item. Our original implementation utilized an FVA based on the "Contained By" relationship. Which works great for items that are contained directly by the segement. If there is a hierarchy however, this apporach no longer works. The proposed solution from the experts was for us to use a computed field with the getFieldValue(DocumentID(),"field we care about"); function instead of using an FVA.

So... "Going back to an FVA" is an option of sorts. Doing so puts back at our previous problem: How do we get fields contained in a segement when we're in a node item?

If we go back to an FVA, how do we get access to the segment fields from the node item?

-Sean

[mbohanon]

You may want to consider a trigger that will:

1. Update all node items for the field of interest when the field of interest in the segment changes and
2. Set the field of interest when the "Contained By" relationship changes.

You may have a number of fields you want to do this on, so a trigger becomes more efficient. A some examples would be:

1. intDocumentID - usefull for qbrs. I've had some issues trying to use "Document ID" in the past, but can't remember exactly what.
2. Status flags for editability
3. Document Title - so you can see what document the content item belongs to.
4. Assigned User
5. intReferenceID - usefull for qbrs, constraints for sub segments.

One thing to note: The Document ID field is a little wierd. Grab the Document ID value from the parent of the delta bean. Don't try to use getNewFieldValue("Document ID").