P5
A DESCRIPTION OF THE REQUEST :
DataSets should provide the ability to position them, meaning that the state that indicates what row the DS is pointing to should be easily manipulated by a client. The DataSet<T> interface should either define the absolute() and relative() methods - like ResultSet/RowSet - or the contract of List.get(int) should be refined to indicate that this method repositions the DS. Of course, this would only be applicable to a scrollable DataSet.
JUSTIFICATION :
The current semantics of the getRow()/insert()/modify()/delete() methods require the client to use an Iterator to walk through the DS. This paradigm is far from ideal when using the DS as a model in a visual component or similar use case (and would very quickly break down for large-ish data sets).
For instance, a JTable might be given a table model that uses a DataSet as its underlying data source. Events on the table might directly translate into method calls (i.e. CellEditor.stopCellEditing() invokes DataSet.modify()).
Without the ability to position the DataSet, its updatability seems to be of limited use. Either the client must "shadow" the DS with another structure and bulk-propogate changes back to it by walking an iterator, or simply provide @Update queries on a BaseQuery interface to write changes back to the DB.
DataSets should provide the ability to position them, meaning that the state that indicates what row the DS is pointing to should be easily manipulated by a client. The DataSet<T> interface should either define the absolute() and relative() methods - like ResultSet/RowSet - or the contract of List.get(int) should be refined to indicate that this method repositions the DS. Of course, this would only be applicable to a scrollable DataSet.
JUSTIFICATION :
The current semantics of the getRow()/insert()/modify()/delete() methods require the client to use an Iterator to walk through the DS. This paradigm is far from ideal when using the DS as a model in a visual component or similar use case (and would very quickly break down for large-ish data sets).
For instance, a JTable might be given a table model that uses a DataSet as its underlying data source. Events on the table might directly translate into method calls (i.e. CellEditor.stopCellEditing() invokes DataSet.modify()).
Without the ability to position the DataSet, its updatability seems to be of limited use. Either the client must "shadow" the DS with another structure and bulk-propogate changes back to it by walking an iterator, or simply provide @Update queries on a BaseQuery interface to write changes back to the DB.