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.

  Data = $@

"Data": The value of this field is described above. It can be a scalar, hashref, arrayref, or undef.

Accessor Functions

"$resp->code()"
"$resp->id()"
"$resp->datatype()"
"$resp->data()": Get/Set accessor funtions to the same data described in the "new()" constructor.

EXPORT

None by default.

AUTHOR

Sean Egan, <seanegan:bigfoot_com>

POD ERRORS

Hey! The above document had some coding errors, which are explained below: