Result Sets: ========= In the latest ooSQLite implementation I have implemented allowing the user to specify the format of a result set. Here are the details:
There are 3 new constants that specify the format: OO_ARRAY_OF_DIRECTORIES, OO_ARRAY_OF_ARRAYS, and OO_STEM_OF_STEMS. By default the format is array of directories. The default can be changed either on a process-wide, database-wide, or prepared statement-wide basis. The default can also be over-ridden on a specific method invocation where the method returns a result set. Each of the 3 main classes has a recordFormat attribute. Setting the ooSQLite::recordFormat changes the default process wide. The ooSQLiteConnection::recordFormat attribute changes it for that database connection. And the ooSQLiteStmt::recordFormat changes it for that prepared statement. In writing the above, I noticed it is not a database-wide default, but rather a database connection-wide default. SQLite allows multiple concurrent connections to a database. Each ooSQLiteConnection object is a single connection to a database. You can have multiple ooSQLiteConnection objects all connected to the same database concurrently. SQLite handles the concurrent access to a database so in ooSQLite you can use multiple ooSQLiteConnection objects from different threads, or a single object from different threads. Note, in the 'classic Rexx' interface, the default format is a stem of stems. The default can be changed either by over-riding the default in a specific function call that returns a result set. Or, if the programmer is willing to use objects a little bit by using: .ooSQLite~recordFormat = .ooSQLite~OO_ARRAY_OF_XXX. In the testing subdirectory I've added 4 programs, execTest??.rex that demonstrate the above. One thing: the discussion on result sets kind of side-tracked me. SQLite doesn't really use the paradigm of result sets. Rather it uses a paradigm of stepping through a prepared statement, or it uses callback functions. There is only 1 API that can return a result set, exec(). This is a convenience API that is a wrapper for using a prepared statement. The exec() API is used through ooSQLiteConnection::exec(), or through the oosqlExec() function. SQLite doesn't support the idea of a cursor. You can't jump ahead to record 100, or go back to record 15. You have to step through each record, in order, one by one. In your Rexx program you can of course add your own support for a cursor by stepping through all the records and placing them in an array or other data structure. Once you have that, you can obviously go to any record you want. In the testing program are these 4 programs: execTestA.rex ==> result set is an array of arrays execTestD.rex ==> result set is an array of directories execTestS.rex ==> result set is a stem of stems and execNoExecTest.rex ==> implements the exact same task as the above 3 programs, but steps through the prepared statement. The execNoExec.rex program is actually easier to write and looks cleaner, (IMO,) than the other 3. Class Names: =========== I made these changes to class names based on what was talked about so far: ooSQLiteDB ==> ooSQLiteConnection ooSQL ==> ooSQLiteConstants In addition, ooSQLiteConstants is a mixin class now and all the ooSQLite classes inherit it. While rewriting the current ooSQLite programs I have, I noticed that this seems very convenient and useful to me. You can have code like: do while stmt~step == stmt~ROW or -- Set the result set format to an array of arrays: .ooSQLite~recordFormat = .ooSQLite~OO_ARRAY_OF_ARRAYS Documentation =========== I have a oosqlite.pdf reference manual now. It lists every class, method of the class, constant, and function. Practically every one of these entries is simply a template entry at this point. I'm going to try and fill in the arguments and return parts of the template as soon as I can. The prebuilt package has oosqlite.pdf in the doc directory. In addition, there is a stand alone oosqlite-r7863.pdf file that can be downloaded from the SourceForge directory. My intent is to replace oosqlite-r7863.pdf periodically with oosqlite-rNNNN.pdf as I complete portions of the reference. (NNNN stands for the svn revision number so you can tell if you need the new version or not. The first page of the reference has the svn revision number on it.) Prebuilt Packages on SourceForge: =========================== It is also my intent to update the "preview" package on SourceForge fairly regularly as changes are made. The ReleaseNotes file is displayed on the SourceForge page. Towards the bottom of the Releases notes is a cumulative changes section. You can scroll down to see a synopsis of what has changed from one package to the next. -- Mark Miesfeld ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ _______________________________________________ Oorexx-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/oorexx-devel
