view release on metacpan or  search on metacpan

README  view on Meta::CPAN

              be included in the hiddenFilter.

          always_select => 1
              tells OptimalQuery to always select the column regardless if
              it isn't explicitly being used in the show. This does not
              automatically make it shown to the user, but it will be
              available to the developer in callbacks.

          select_sql => (STRING | ARRAYREF)
          filter_sql => (STRING | ARRAYREF)
          sort_sql => (STRING | ARRAYREF)
              SQL to use instead of the default SQL for the select for the
              context described.

          date_format => (STRING)
              if column is a date and date format is specified, OptimalQuery
              will write SQL to use the date format appropriately.

              Note: Oracle's date component also has a built-in time
              component. If the data is '11/24/2005 14:56:45' and the
              date_format is 'MM/DD/YYYY', the date will show up as
              '11/24/2005'. If a user tries to filter on date '11/24/2005'
              Oracle will only match '11/25/2005 00:00:00' leaving out
              results the user probably thinks should be included. In this
              case, the developer should trunc the date. Trunc strips the
              time component from a date field. Example:

                DATE_COL => ['DEP1', 'trunc(dep1.date_field)', 'My Date',
                               { date_format => 'MM/DD/YYYY' } ]

    joins => { JOIN_ALIAS => [ DEP, JOIN_SQL, WHERE_SQL, OPTIONS ], .. }
      describes what tables to join in order to fulfill the dependancies
      used by the fields described in the SELECT HASHREF.

      JOIN_ALIAS (STRING)
          is the alias for the table or inline view decribed in the
          JOIN_SQL.

      DEP (STRING | ARRAYREF | undef)
          describes required joins that this join depends upon. This should
          be "undef" if and only if this is defining the driving data set.

      JOIN_SQL (STRING | ARRAYREF)
          describes the SQL that is used in the join clause for the
          generated SQL. Example: "LEFT JOIN dept ON (emp.dep_id =
          dept.id)". If this describes the driving table, only the table
          name is needed. Inline views can also be used. Make sure you
          specify the alias on the view! Example: JOIN ( SELECT * FROM emp
          WHERE is_active = 'Y') active_emps

      WHERE_SQL (undef | STRING | ARRAYREF)
          This is deprecated. It was used to describe the SQL in the where
          clause that was needed to join the table described in the from
          clause. Since SQL-92 allows developers to put the join SQL in the
          join, this should not be used.

      OPTIONS (undef | HASHREF)
          The following KEY/VALUES below describe OPTIONS used by the joins
          configuration.

          new_cursor => 1
              tells OptimalQuery to open a new cursor for this join. This
              can be used to select and filter multi-value fields.
              Optionally, an order_by param can be specified to sort the
              results returned by the cursor as such:

          new_cursor_order_by => "some_field.id"

    *OPTIONAL CONFIGURATION*
      The following KEY/VALUES below for %CONFIG in the call to "new" are
      NOT required.

    AutoSetLongReadLen => 1
      Tells OptimalQuery to automatically set "$dbh->{SetLongReadLen}". Used
      only in Oracle. Enabling this setting may slow down OptimalQuery since
      it needs to do extra queries to set the length if LOBS exist. This is
      only enabled by default when using Oracle.

    check => 0
      Tells OptimalQuery to do additional checking to make sure the amount
      of rows in the driving table is equal even when including other joins.
      It is off by default because there can be a significant performace hit
      when enabled.

    debug => 0
      sends debug info to the error_handler (STDERR is default)

    error_handler => sub { ($err) = @_; }
      intercept messages sent to the error handler. Very useful if you are
      running in a mod_perl env and want to redirect error messages using
      "$areq->log_error($msg)".

    filter => "[SELECT_COL_ALIAS] like 'foo' AND .."
    hiddenFilter => "[SELECT_COL_ALIAS] like 'foo' AND .."
    forceFilter => "[SELECT_COL_ALIAS] like 'foo' AND .."
      Filters add SQL to the where clause. If a CGI param called 'filter' or
      'hiddenFilter' are provided, the CGI param value is used instead. The
      value of a forceFilter cannot be overridden. Users can manipulate a
      filter using the filter dialog tool. The hiddenFilter can only be
      manipulated using the GET param. Filters allow developers and end
      users to add SQL to the where clause. The filter grammar is described
      in the *FILTER GRAMMAR* section.

      For example:

        <a href=/Search?filter=".escape_uri("[NAME] like 'foo'")

    module => { OverloadModuleLabel => PerlModuleName, .. }
      This is an advanced feature that can help perl guru's change the
      factory blueprints for optimal query modules instantiated by
      CGI::OptimalQuery.

    named_filters => { NORMAL_NAMED_FILTER, CUSTOM_NAMED_FILTER, .. }
      allow developers to create complex predefined sql for insertion in the
      where clause by the 'filter' and 'hiddenFilter' parameters. There are
      two types of named_filters: "normal" and "custom". Normal named
      filters are defined with static SQL. Custom named filters are dynamic
      and most often take arguments which influence the SQL and bind params
      generated via callbacks.

      NORMAL_NAMED_FILTER
            filterNameAlias => [ DEP, SQL, NAME ]

          DEP is a string or an ARRAY of strings describing the dependancies
          used by the named filter. SQL is a string or an arrayref with
          SQL/bind values that is used in the where clause when the named
          filter is enabled. The NAME is used to describe the named filter