By design, a cursor is a in memory result set. As a result set, it contains many records - or rows - and each row contains columns with values.

I think that is a good idea to define a class to abstract these rows - Zend_Db_Cursor_Row - as well, or make cursors behave as Zend_Db_Table_Rowset - as they share common behavior.

Any opinions?

Added the class skeleton. This code is not tested yet.

Although your approach seens to work well and its simpler than one in my proposal. I believe that using an abstract class is more elegant and expansible than to inject cursors logic directly in statements components. By design, the ref cursors are in memory result sets and do not behaves like a statement, it behaves like a result set (in a Zend_Db_Table_Rowset flavor).

Keeping it under its package decrease the coupling and increases the cohesion of the component, allowing to allocate ne DBMS ref cursors at a glance.

I am in 100% agreement that this is the proper approach to take. My first pass was really just to flesh out the ideas, and get some workable code to test. I would like to also modify Zend_Db_Statment_Oracle to be "cursor aware" so that in addition to your use case (Theory of Operation) above, you could do the following:

As you said, by design a cursor is an in memory result set. It's that point which makes me feel that you shouldn't be calling execute() on a cursor, that should be done on the Statement. If we make the Statement "cursor aware" it becomes much more fluid for the program to do the above, while still allowing the use case you have proposed for those that prefer modeling the PHP/OCI8 coding style.

What I'm currently working on looks similar to what you have proposed, though slightly different. Let me see if I can make this look right...

Zend/
  Db/
    Cursor/
      Oracle/
        Exception.php
      Exception.php
      Interface.php
      Oracle.php
    Cursor.php

Where Zend_Db_Cursor is an abstract class that implements Zend_Db_Cursor_Interface and Zend_Db_Oracle_Cursor extends Zend_Db_Cursor. I have skeleton code to complete all the above classes, but haven't gotten around to testing them yet. I'm hoping to have time today (after meetings) to start working on that.

Re-assuming the proposal after a long break.

Just finished a new component draft, updating within a week.

I tried the alpha component and it seems that Statement is not well created, i get this error :
Warning: oci_bind_by_name(): supplied argument is not a valid oci8 statement resource

Just updated this proposal. Uploaded the working class skeletons - see the Theory of Operation section.

The alpha version allow to bind a ref cursor in an Oracle statement and to fetch data from it as a rowset.

Next improvement is to allow object flavor access to the Zend_Db_Cursor_Row objects.

If you can, test it and give some feedback.

Thanks

Zend_Db_Row can be accessed as an array ($row['column']) and as an object ($row->column)

Just pushed the package draft in github, the link is http://github.com/brunitto/zend-db-cursor.git

Hello, good work. But in my opinion I believe there should be simpler, as previously stated by Brian, because the cursor in Oracle is a statement and this should be so treated for compatibility as other classes of stock are. If you create an abstract class for cursor depending on the interpretation can be confusing because its definition is sometimes a little differently in each bank, as being fit for a bank but not as a cursor.

How do I put this link: http://framework.zend.com/issues/browse/ZFINC-13 would leave here the implementation I made that solves this problem as yet have no knowledge of how to create a proposal I have just the patch same link above.

Following example of using already testing in Oracle 9i Release 2 (9.2):

SampleModel.php

SampleController.php

Patch:

Archiving this proposal, feel free to recover it when you want to work on it again. For more details see this email.