Been spending some time thinking about this myself, and I think I came to the same conclusions you have about layering the support. I'd say continue down the path you're on, but start giving some thought to how to construct the layer that gets built on top of the lower level details.
I'm thinking one approach might be to have a object that can be retrieved from the database that performs the object-to-relational mappings. The object instances are retrieved and inserted into the database through the intermediate objects. This is a little like the architecture for the various object-to-relation APIs that exist for Java, but without the enclosing container architecture. The tough part is figuring out the syntax for defining the object metadata. Rick On Sun, Jun 3, 2012 at 3:29 PM, Mark Miesfeld <[email protected]> wrote: > 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 ------------------------------------------------------------------------------ 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
