Specifies the primary key. This must be specified, so if you don't have primary keys in your table, you cannot use the Tie::Table (for the whole table. You can use it for a subset of rows specified by the "constraint" param).

In the example above you can use the reference field (company_id) from the "user" table to query the company in which the user work: $company_name = $user->{17}->company_id->{name}.

function1 is the name of the function, which can be used for the back-reference, eg. can be used to determine the user-ids in one company: @user_ids= keys %{ $company->{45}->users }. "users" is the function name in this example.

This is similar to "select", but it can be used only for equality test. The main advantage is that it can be used for deletion and insertion. If you insert something into a table, which has constraint parameter, all the values in the constraint hash is set in the new record. This constraint is used internally, when somebody creates a back reference by a back-reference function.

There is two kind of reference in this module. All two are set up by "ref" parameter in the table. If you use a "ref" parameter, then the "back_ref" is automatically created in the other table (if not already exists).

All the sql queries are cached in this module. This must be rethought, because sometimes it is not the best solution. I want some extra parameter for caching in the newer versions. Now all the query results are cached for 10 seconds. This value can be tuned by setting the Tie::Table::CACHE_SECS variable.

The global cache object is $Tie::Table::cache, and it can be invalidated by the $Tie::Table::cache->invalidate_cache call.

The cache is hierarchical (it is stored in tree structure). If you want to invalidate the whole cache, you can call:

The current implementation cannot handle tables, which is used to express a relationship between two data. These tables normally have two foreign key fields. If you want to use them with that module, then you need to add a unique identifier for each row. For examply by using postgresql and if your table looks like this:

You can write the following definition for this table (assumed that users and day tables are already defined):

This module is now usable for one purpose. I have profiled it, and I've found that the "read_data" function is the most time-consuming. This must be handled by re-organizing the cache.

Caching can be set globally right now (by $Tie::Table::CACHE_SECS) but it must be more fine-grained in the future.