On Sat, Jun 2, 2012 at 6:04 AM, Rick McGuire <[email protected]> wrote:
> Some more musing on the examples.
Rick,
After thinking about your comments and Jon's for a day ...
ooSQLite at this point really has only 2 main classes:
.ooSQLiteDB (which is actually a database connection not a database)
.ooSQLiteStmt (which represents a SQLite prepared statement)
These 2 classes are basically a low-level abstraction of the SQLite
APIs. The methods of the class are almost entirely a one-to-one
mapping of the SQLite APIs.
The other classes in the example programs are, rather hastily put
together, classes to use the lower level abstractions.
I think I envisioned people putting together their own 'frameworks'
that used the low level abstractions. Mostly because that's what I'd
prefer, to have access to all the SQLite APIs and put together what I
wanted.
Maybe this would be a better approach over all:
Leave the low level objects sort of the way they are. Add an
implementation of a "DataBase" object that would be a higher level
abstraction. The DataBase object would use the low level objects to
do the actual work, but present an easier to use, (and better designed
from an OO point of view,) interface.
This would allow people to use the DataBase object without having to
learn the details of how to actually program SQLite. But, still free
to create their own higher level abstraction using the low-level
objects if they wanted.
Taking that one step further, maybe put the DataBase class (and any
supporting classes of the higher level abstraction) in its own file
and leave the low-level objects in its own file. Then, someone like
Jon (for instance) that only wanted to deal with the high level
abstraction would use:
::requires 'ooSQLiteDatabase.cls'
and someone else would be free to create their own abstraction and use:
::requires 'ooSQLite.cls'
See below for the application of this to your comment:
> In the insertIntoDatabase example, the SQL statements are constructed using
>
> sql = "INSERT INTO contacts (fName, mName, lName, nickname, title)" || -
> " VALUES('"c[1]"', '"c[2]"', '"c[3]"', '"c[4]"', '"c[5]"');"
>
> This has a drawback that the values inserted are content sensitive. A
> ' character in any of the values will cause this to fail.
Yes. SQLite itself has an API that will correctly escape things. For
both this and the following:
> This sort
> of SQL statement construction is also vulnerable to SQL injection
> exploits.
The SQL statement construction here is local, not part of ooSQLite
itself. The local program knows there are no quotes in the content
and there can be no SQL injection problems because the the local
program is producing the actual value to be inserted.
> A nicer approach would be to provide an object that the
> database would use to retrieve the individual values by name. For
> example, for this example, you could define
>
> ::class contact
> ::attribute firstName
> ::attribute middleName
> ::attribute lastName
> ::attribute nickname
> ::attribute title
>
> and construct the statement something like this:
>
> sql = "INSERT INTO contacts (fName, mName, lName, nickname, title)" || -
> " NAMES(firstName, middleName, lastName, nickname, title);"
This is good and I've used something very similar in some ooDialog
examples where the 'database' data was in a CSV file.
This is what, I'm thinking, should be in a higher level DataBase object.
The ooSQLite extension could provide a good default 'DataBase' object.
Then this (the entire insert part we are talking about) would become more like
db = .ooSQLiteDatabase~new(fileName)
db~open
contact = .Contact~new(args)
db~insert(tableName, contact)
The insert() method would do all the work of creating the low-level
prepared statement using the contact object. (With some scheme of
determining the field names, maybe needing another argument to
insert().)
> stmt = .ooSQLiteStmt~new(db, sql, contact)
>
> The contact instance would then use the names in the statement to
> retrieve the individual values. This could also work on a retrieval,
> where an instance of an object is provided and the corresponding
> assignment methods are called to set the retrieved values. This would
> work well with directory objects as well, and with a small tweak,
> could even recognize stem objects and set and retrieve the values
> there as well.
And the above would be part of the higher level 'DataBase' object.
Does that make sense?
--
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
