NAME

POE::Component::LaDBI::Response - Class encapsulating responses from POE::Component::LaDBI::Engine.

SYNOPSIS

  use POE::Component::LaDBI::Response;

  $resp = POE::Component::LaDBI::Response->new
           (Code     => 'OK',
            HandleId => $sth_id,
            Id       => $request_id,
            DataType => 'TABLE',
            Data     => $fetchall_arrayref_ret);

  $resp->code;
  $resp->handle_id;
  $resp->id;
  $resp->datatype;
  $resp->data;

  $resp->id;

DESCRIPTION

$resp->new()

Args:

For the keys, capitalization does not matter. Internally the keys are lowercased.

Code

String identifier representing the error result of the request.

Valid Code values are:

OK: The POE::Component::LaDBI::Request succeeded as far as POE::Component::LaDBI::Engine is concerned.
FAILED: The POE::Component::LaDBI::Request failed. DataType will be set to either ERROR or EXCEPTION.
INVALID_HANDLE_ID: The POE::Component::LaDBI::Engine instance does not have a record of the $request-handle_id>.

Id

This is the unique cookie from the POE::Component::LaDBI::Request ($req-id>) this POE::Component::LaDBI::Response object corresponds to. There is a one for one relationship between requests and responses.

DataType

The type of data returned in Data. If you are constucting a POE::Component::LaDBI::Response object you must supply this field. However, if you are just useing the POE::Component::LaDBI::Response object returned from POE::Component::LaDBI::Engine::request() you can usually ignore this field. This is because all requests have a fixed and known response data type.

TABLE

Data is an array ref of array refs to scalars.

  Data = [ [row0col0, row0col1, ...],
           [row1col0, row1col1, ...],
           ...
         ]

NAMED_TABLE

This one is odd. See the description of selectall_hashref() in DBI. For *_hashref() calls in DBI you have to provide the database table field which will be the hash key into this hash table. The values corresponding to each key is a hash of the rows returned from the select or fetch. I did not invent this and do not quite understand why.

  Data = {
          row0colX_val => {col0_name => row0_val, col1_name => row0_val, ...},
          row1colX_val => {col0_name => row1_val, col1_name => row1_val, ...},
           ...
         }

ROW

Data is an array ref of scalars.

  Data = [ elt0, elt1, ... ]

NAMED_ROW

Data is an hash ref containing name-value pairs of each data item in the row; the name is the column name, the value is the column value.

  Data = { col0_name => elt0, col1_name => elt1, ... }

COLUMN

  Data = [ elt0, elt1, ... ]

RC

Return code is a scalar valude returned from the DBI call.

  Data = $rc

RV

Return Value is a scalar value returned from the DBI call.

  Data = $rv

SQL

This is the data type for the return value from DBI::quote() call.

  Data = $sql_string

ERROR

There was an error for the DBI call. This indicates the DBI call returned undef. The data value is a hash ref with two keys 'err' and 'errstr'. These keys corresponed to the DBI calls of the same name: $h->err and $h->errstr.

  Data = { err => $handle->err, errstr => $handle->errstr }

EXCEPTION

There was an exception thrown from the DBI call. This indicates the DBI call called a die(). All DBI calles executed by POE::Component::LaDBI::Engine are wrapped in a eval {} to catch any exceptions, like when RaiseError is set.