I understand that in some cases it might be desirable to automatically create an index based on some condition (e.g. When rule), but in general it seems to me that most of indexes will be established at design time.
Based on this my understanding it that a Declare Index subscription to a property value change should be optional and not mandatory
So my question is: Is that not the case? Does it always evaluate when the property changes?
I checked on PRPC and found that some properties referenced by Declare Index rules posses no relations in the PRPC's Declarative Network (Property, Advanced, Explore & Declarative Network)
I get the feeling that I'm not really understanding the full meaning and purpose of this Declare Index rules and the documentation does not really help much.
I'd really appreciate if somebody could explain it on detail.
As a point, the Declarative Network display only shows relationships among properties that are computed by a Declare Expression. We can safely set this display aside when trying to understand Declare Index as it does not provide a view into any indexes (indices for grammar-snobs) we may have created.
As to your question:Does it (Declare Index) always evaluate when the property changes?
Yes, it does. Once you define an index using the Declare Index ruleform, Pega 7 automatically maintains the index data using forward chaining. Granted, you can intercept whether or not the index actually updates, but the Declare Index does depend on the Page.
Finally, as to the quiz question, it's asking about those declarative-type rules that do not establish a dependency on a property. Declare Trigger and Data Page (the artist formely known as Declare Page) are the only two declarative-type rules that do not depend on any specific property to automatically execute.
I tend to find this article in the Help file useful when trying to understand Declare Index:
I don't mind the discussion - mostly because I have always been as curious and always to busy to dig into it - so let's go for it. One thing I have learned about working w/ products like this is there is always a back-story.
A competitor of Pega had a rather interesting setup; a "process server" engine and a "reporting" engine. The marketing story was about how clever an idea it was to keep reporting out of the day-to-day transactions engine. The back story was the reporting engine wasn't built unitl years after the process server engine - and it turned out to be easier to build it separtely than try to recode the process server engine.
Let me talk to some product folks and get the back-story to these questions.
What I understand is that the Declare Index is used only for Page List or Page Group because exposing a single-value property in the case or a Page results in a 1 case to 1 property value scenario, so you can expose the property column in the same Work table.
But for a Page List or Page Group, you will need a second table otherwise you will not know how many columns to actually create in the Work table since the number of records differ from case to case. So you have a situation where a parent-child table relationship is more suited in this case. Hence, the Index- classes are created to map to the newly created Index- child table. This allows a 1 case to many property values scenario.
I've always been lead to believe that the Declare Index is then responsible to maintain this parent-child relationship between the values in the 2 tables. Any change in the property value will trigger the Declare Index to run and update the child table accordingly, hence Declare Index's dependence on properties.
However, I'm curious as well to know the back-story as Eddie suggested.
After further investigations I think the indexes work more or less like this:
All indexes are kept in separate tables. That means that there is no thing as exposing the property in the same Work table ** ***
The index tables are accessed using a concrete Index- class
Index- class needs to have the pxInsIndexedKey, pxIndexCount and pxIndexPurpose properties, as well as all the properties in the source class which will be part of the index
The order of the properties refeneced in Index- class is important, as it determines how the data is sorted in the indexed table
The table mapped to the Index- class needs to expose as separate columns all the properties referenced in it. So if the index is made of two properties, e.g. ZipCode and City, the table should have 5 columns (pxInsIndexedKey, pxIndexCount, pxIndexPurpose, ZipCode and City).
The Declare Index rule is responsible for writing to the Index- class, adding or removing entries whenever a commit operation updates the properties referenced in it. Basically it keeps the Work data in sync with the index data tables. This is done via forward-chining
The Index- class then is used to access the index data and speed up Reporting, Lists, etc
As a best practise, indexes are defined on embedded Page List/Group, never on top-level single value properties (is that even possible??) ***
Does it make sense?
This is all I could make sense out of the documentation available.
** When optimizing properties used in classes which refer to local tables created with the table creation wizard, the process is different. Rather than creating an Index- class and Declare Index, PRPC simply adds an additional column to the table where the data is stored. If the data was stored in pr_other, a dedicated table is created automatically.
*** After further investigation, it seems like it is possible to optimize single value properties at the work top level. In this case the system adds additional columns to the work table.