2.2 Accessing a table
AllApplicationManualNameSummaryHelp

  • Documentation
    • Reference manual
    • Packages
      • Managing external tables for SWI-Prolog
        • Managing external tables
          • Accessing a table
            • Finding record locations in a table
            • Reading records
            • Searching the table
              • in_table/3
            • Miscellaneous

2.2.3 Searching the table

in_table(+Handle, ?Fields, -RecordPos)
Searches the table for records matching Fields. If a match is found, the variable (see below) fields in Fields are unified with the corresponding field value, and RecordPos is unified with the position of the record. The latter handle may be used in a subsequent call to read_table_record/4 or read_table_fields/4.

Fields is a list of field specifiers. Each specifier is of the format:

FieldName(Value [, Options])

Options is a list of options to specify the search. By default, the package will search for an exact match, possibly using the ordering table associated with the field (see order option in new_table/4). Options are:

prefixUses prefix search with the default table.
prefix(Table)Uses prefix search with the specified ordering table.
substringSearches for a substring in the field. This requires linear search of the table.
substring(Table)Searches for a substring, using the table information for determining the equivalence of characters.
=Default equivalence.
=(Table)Equivalence using the given table.

If Value is unbound (i.e. a variable), the record is considered not specified. The possible option list is ignored. If a match is found on the remaining fields, the variable is unified with the value found in the field.

First, the system checks whether there is an ordered field that is specified. In this case, binary search is employed to find the matching record(s). Otherwise, linear search is used.

If the match contains a specified field that has the property unique set (see new_table/4), in_table/3 succeeds deterministically. Otherwise it will create a backtrack-point and backtracking will yield further solutions to the query.

in_table/3 may be comfortable used to bind the table transparently to a predicate. For example, we have a file with lines of the format.1This is the disproot.dat table from the AAT database used in GRASP

    C1C2,Full Name
    

C1C2 is a two-character identifier used in the other tables, and FullName is the description of the identifier. We want to have a predicate identifier_name(?Id, ?FullName) to reflect this table. The code below does the trick:

    :- dynamic stored_idtable_handle/1.


    idtable(Handle) :-
            stored_idtable_handle(Handle).
    idtable(Handle) :-
            new_table('disproot.dat',
                      [ id(atom, [downcase, sorted, unique]),
                        name(atom)
                      ],
                      [ field_separator(0',)
                      ], Handle),
            assert(stored_idtable_handle(Handle)).

    identifier_name(Id, Name) :-
            idtable(Handle),
            in_table(Handle, [id(Id), name(Name)], _).