InTrust 11.6 - InTrust SDK Reference

Getting Records

A repository search returns data wrapped in a polymorphic IUnknown interface, as described in Getting and Putting Data. To interpret the data as repository records, cast it as IBulkRecord2.

Example (C#)

class MyObserver : IDisposable, REPOSITORYSERVICESLib.IObserver
{
    public REPOSITORYSERVICESLib.ICookie m_cookie;
    public MyObserver()
    {
    }
    public void OnDone()
    {
        Console.WriteLine("Search done");
    }
    public void OnError(int hr, string description)
    {
        Console.WriteLine("Search error: {0}", description);
    }
    public void OnNext(object data)
    {
        if (data != null)
        {
            IBulkRecord2 bulk_record2 = (data as IBulkRecord2);
            List<record2> records = bulk_record.GetRecords().Cast<record2>().ToList<record2>();
            int record_count = 0;
            foreach (record2 my_record in records)
            {
                ++record_count;
            }
        }
        System.Runtime.InteropServices.Marshal.FinalReleaseComObject(data);
    }
}

For details about what repository records are, see Repository Record Data Structures.

Getting Events

A repository search returns data wrapped in a polymorphic IUnknown interface, as described in Getting and Putting Data. To interpret the data as event records, cast it as IBulkEventWithReadExtensions.

Example (C#)

class MyObserver : IDisposable, REPOSITORYSERVICESLib.IObserver
{
    public REPOSITORYSERVICESLib.ICookie m_cookie;
    public MyObserver()
    {
    }
    public void OnDone()
    {
        Console.WriteLine("Search done");
    }
    public void OnError(int hr, string description)
    {
        Console.WriteLine("Search error: {0}", description);
    }
    public void OnNext(object data)
    {
        if (data != null)
        {
            IBulkEventWithReadExtensions bulk_event = (data as IBulkEventWithReadExtensions);
            List<event_with_read_extensions> events = bulk_event.GetEvents().Cast<event_with_read_extensions>().ToList<event_with_read_extensions>();
            int event_count = 0;
            foreach (event_with_read_extensions my_event in events)
            {
                ++event_count;
            }
        }
        System.Runtime.InteropServices.Marshal.FinalReleaseComObject(data);
    }
}

For details about what event records are, see Event Record Data Structures.

Composing REL Queries

REL is an expression language developed specifically for InTrust, and it is used for multiple purposes besides repository searching.

The following topics about REL in the InTrust Customization Kit contain information that is fully applicable to queries used for searching in repositories:

• Words
• Expressions
• Operators
• Functions

However, due to the specifics of how repositories operate, there are some limitations on what you can include in your queries and nuances that affect performance. These peculiarities have to do with the following:

• Use of punctuation in field values
• Whether "equals" or "contains" semantics are used

Punctuation and Other Non-Alphanumeric Characters

Some characters, such as curly braces and the hyphen, are treated in a special way by the repository indexing engine. A query that includes these characters is automatically transformed during an indexed search, even though the query itself may be perfectly valid. The indexing engine splits the query into substrings at these characters and uses the substrings to make the clauses of an AND expression.

As a result, these characters are effectively removed from the index. This affects how well irrelevant data is filtered out and, consequently, how fast queries are evaluated. The following is a list of such characters:

- \ & { } ( ) [ ] < > , ! ? .

You can deal with this limitation in the following ways:

"Equals" Versus "Contains"

In a repository search, a query that uses "equals" semantics (the striequ REL function) is always evaluated faster than a similar query using "contains" semantics (the substr REL function). Queries with "does not equal" semantics are even slower.

Regular expressions (the regexp REL function) are slowest.

Searchable Event and Record Fields

This topic lists the field names that you can use in your REL queries when you search for events or records in a repository using the IObservable and IObserver interfaces.

The results of a search are polymorphic and can be cast to events or records as necessary. In addition, you can treat the contents of the repository as either events or records and use either event field names or record field names. However, you cannot mix event and record field names in the same query.

For example, if your repository contains custom records with filled-in insertion strings, it is convenient to treat the records as events for easy access to insertion string contents (see Insertion Strings below).

Event Fields

Insertion Strings

To look in insertion strings and resolved insertion strings, respectively, use the following field names:

• InsertionStringN
• ResolvedInsertionStringN

where N is the number of the string.

Examples of REL expressions:

in( InsertionString10, "rei", "(\\b|\\W|^)is1608133597" );

striequ(ResolvedInsertionString2,"is");

Record Fields

Most of the fields defined in the record data structures (see Repository Record Data Structures) can be used in search queries:

• directory_tag_1
• directory_tag_2
• directory_tag_3
• directory_tag_4
• field_1
• field_3
• field_4
• file_tag_1
• file_tag_2
• file_tag_3
• file_tag_4
• formatting_record_field
• string_field_1
• string_field_2
• string_field_3
• string_field_4
• string_field_5

Note that some fields contain integers and others strings.

Examples of REL expressions:

field_1 = 123;

striequ(directory_tag_1,"blue");

striequ(formatting_record_field,"green");

striequ(string_field_1,"cerise");

file_tag_1 = 5385;