ODG::Record is designed for efficient streaming,
i.e.
accessing one-record-at-a-time.
For conventional record iterators,
a new row object is created for each record,
slots are initialized,
data are filled and types are checked.
Not all of this is desirable.

If every row based record,
populates in the same manner,
it is hugely inefficient to instantiate a new object for each record.
This is especially true of Moose-based class.
( This is not a knock against Moose.
ODG::Record uses Moose extensively.
)

The approach taken by this module is to instantiate a single object and changing the data for that object.
To do this,
a ArrayRef data slot is created.
When the next record is used.
The ArrayRef is pointed to a different Array,
i.e.
the next record.
In not incurring the expensive of object instantiation for each record we have a huge performance win.
(See tables below.)

The downside is that the checking / validation in new object creation is lost.
This may or not be acceptable depending on the situation.
Generally,
when the records are well-defined and well-maintained,
i.e.
from a database,
this is not an issue.
The data from one record to the next is fairly consistent.

Encapsulation is also be lost.
Again,
whether this is acceptable depends on the situation.
There are several methods of object recycling ( as opposed to creating a new object).
They are:

Notably,
encapsulation is not lost for the entire object.
It is done only for the attributes that point to the _data slot.
These are identified by the meta-attribute trait,
index,
as well as a non-negative integer specifying the position in the ArrayRef.

* creating a new ODG::Recrod object.
* using a standard accessor,
* using an lvalue accessor (not officially supported by Moose -and- may break encapsulation.
( Since this is Moose,
other Moose techniques can be used for validation,
e.g.
after method) * direct access (breaks encapsulation).

This idea can be extended to a RecordSet where the _data slot contains an ArrayRef[ArrayRef]. A pointer object is then used to identify the current record. This may be advantageous when batching is more appropriate. Some reasons for this might be related to:

* I/O constraints, especially latency provide for more
efficient processing through batch methods
* Processing requires look-backs or look-aheads
* Processing benefits from batch methods. i.e. records
are sorted in order and one event needs to be triggered
for all records of one type.

In the original incarnations of this module, metadata was placed in a seperate _metadata slot. This was overkill, since the only metadata needed was the record order. Starting at version 0.30. The metadata is implemented using Moose meta-attribute traits. Please see: