I'm following this with interest.
One thing that occurs to me is that ooSQL.cls is not a specific enough name
for this class. I hope that in the future there will be similar frameworks
for other databases (as the SQLLite people are the first to admit that it
is not suitable for multiple client use).
perhaps ooSQLLiteConst.cls would do as a name or you might think of
something more suitable.
I have made use of two ooRexx designed SQL frameworks, both wrappers for
Firstly oRexxSQL which provided two approaches, one allowing a query to
emulate a stream, and the other allowing cursoring through a result set.
I found it quite confusing with it's miriad methods, and after I found a
way to use it to return data settled down to use a couple of classes and
I was happy with that until I saw Lee Peedin's approach, which returned a
dataset as an array of directory objects. I have since been using an
adaptation of that and as a user I am very satisfied.
I made a rather odd design decision in my adaptation which I have never
been sure whether or not I regretted, the DML methods all return true if
there is an error and false if not. This has saved me hundreds of lines of
code, but I am unsure that it reads well.
The main methods It provides are connect, disconnect, query (ie select
queries), execute (ie the other DML queries and DDL queries), commit,
rollback, and describe. Where a dataset is returned it is at the rows
attribute. Other main attributes are database, rowcount, details (the
contents of the status stem passed back by rexxSQL, last_insert_id.
I mention this in case it is helpful.
keep up the good work,
On 2 June 2012 18:15, Mark Miesfeld <miesfeld@...> wrote:
> On Sat, Jun 2, 2012 at 5:28 AM, Rick McGuire <object.rexx@...>
> > Found some time to start looking at ooSQLLite implementation.
> Great, thanks Rick. I was hoping to get some feedback on the
> implementation, which really is completely flexible at this point.
> > I'm
> > guessing you don't have a draft of the APIs yet, which is really what
> > I was interested in looking at right now.
> Yeah, I've only started a draft in DocBook, it doesn't even compile
> yet. You could look at ooSQLite.cls which contains all the classes
> and methods. It is almost entirely implemented in native code so the
> file is mostly just a listing of the methods of each class.
> This is my original approach:
> SQLite provides a large number, (I think around 200,) C APIs.
> However, only a small subset of them are really needed to effectively
> create and use databases. I would like ooSQLite to eventually be
> complete, that is to have access to all the APIs, except probably for
> some where it just doesn't make sense.
> I wanted to wrap up the APIs in classes and to also provide a more
> 'classic Rexx' interface for those people who shy away from objects.
> The 'classic Rexx' interface is pretty easy to describe and implement,
> it is basically a one to one mapping of ooSQLite ::routines to SQLite
> C APIs. This will excluding any deprecated SQLite C APIs and only
> provide the recommended API for the deprecated API.
> The object orientated interface is the one I'm more interested in and
> hoping to get comments on. I would like to get a good design that the
> committers are happy with before a first release. The only reason for
> what I'm calling the "Preview" release is to have something concrete
> to look at, for discussion.
> Here is an outline of the classes:
> * In SQLite, 95% of what any one would use are is done though APIs
> that either require a database connection or require a prepared
> statement. So the 2 main objects in ooSQLite are:
> Database connection:
> ::class 'ooSQLiteDB' public (in SQLite -> struct sqlite3)
> Prepared statement:
> ::class 'ooSQLiteStmt' public (in SQLite -> struct sqlite3_stmt)
> * Then there are a number SQLite process wide settings for tuning its
> operation and querying its operation. Settings like changing the
> process soft heap limit and queries like getting the high water memory
> used. So I have the ooSQLite class:
> ::class 'ooSQLite' public
> composed entirely of class methods. None of the methods should
> require any ooSQLite objects as arguments. As I said they concern
> things about the database engine itself, they are not database or
> statement specific.
> * SQLite has a large number of numeric defines for return codes and
> arguments. I've put all of these in a separate class composed of
> ::class 'ooSQL' public
> Each constant is named the same as the SQLITE_x constant, minus the
> part and is intended to be used as: .ooSQL~x That is:
> .ooSQL~OK -> is the value of SQLITE_OK
> .ooSQL~ERROR -> is the value of SQLITE_ERROR
> .ooSQL~NOMEM -> is the value of SQLITE_NOMEM
> Since some of the defines are flags, there is one class method,
> merge(), which basically does a binary or of any number of flags so
> that the Rexx programmer doesn't need to try and do that in Rexx code.
> I'm thinking about adding a method that converts the constant to a
> string which is mostly only needed as a debugging aid so that in a
> Rexx program you could print out "NOMEM" rather than having to know
> that NOMEM is 7. Not sure if that is feasible since many of the
> defines are the same numeric value.
> * A mutex class is implemented, which I'm not sure if it is needed,
> or even desirable.
> ::class 'ooSQLiteMutex' public (in SQLite -> struct sqlite3_mutex)
> Its inclusion is based on my design goal of allowing access to the
> complete SQLiter API, where it makes sense.
> And what I saw in ooDialog. Which was that there were a number of
> places where only the simplest things could be done, but it would have
> been just as easy to allow access to a full API. Sure, if you didn't
> understand Windows, you probably couldn't use the not so simple
> feature. But, if you did understand the API, there was no way to take
> advantage of it from Rexx.
> So the ooSQLiteMutex class might be something that only a very few
> Rexx programmers would use, but if it is not included then it is not
> available to those few.
> * There are 2 other classes not written yet.
> One is a back up object, probably ooSQLiteBackUp. SQLite has a struct
> sqlite3_backup with APIs that use the struct to safely allow database
> back up while the database is in use.
> The other is some type of Blob object. SQLite databases can store
> blobs. I'm hazy on how to interface this with Rexx code.
> Lastly, I would like add classes and / or methods that make using
> ooSQLite easier for the Rexx programmer. But, I've never worked with
> databases much at all, and I really have no idea what those classes or
> methods would be. Or if they even exist.
> > There's one thing I picked up as a potential concern looking at the
> > samples, and that's the ErrorHandler class.
> As you saw later this was a local class. As far as the examples go,
> they can be completely redone. Since my database experience is
> limited, my examples may not be very good.
> > stmt~error('INIT', 'contacts)
> > This assumes the DB is obtainable from the stmt object (which is
> > probably a good thing since it was created from the DB).
> It is:
> ooSQLiteStmt::dbHandle() returns the Rexx ooSQLiteDB object used in
> the statement creation.
> One thing I've done is stick mostly to the SQLite API names so that it
> is easy to look up the details of the API in the SQLite documentation.
> In most places the method names make sense to me. This is one case
> where it might not.
> The other thing is the class name ooSQLiteDB. Technically this is a
> *connection* to a specific database, not a database. In general use
> the 2 seem interchangeable to me. But maybe the class name should be
> more along the line of ooSQLiteConn or ooSQLiteConnection depending on
> how much abbreviation you want to do.
> SQLite allows multiple connections to the same database, from the same
> thread or proces, and from mutltiple threads and processes. So a Rexx
> program can or could have any number of ooSQLiteDB objects. The
> compile options used for the database engine are said to produce a
> completely thread safe engine.
> I'm going to come back to the following in another e-mail, this one is
> already pretty long.
> > In a similar fashion, rather than directly instantiate the statement
> > stmt = .ooSQLiteStmt~new(db, sql)
> > it would be better from an oo design standpoint to ask the DB object
> > for a statement:
> > stmt = db~stmt(sql)
> > you might want to create an SQLStmt class that defines the methods of
> > the Stmt class, and then the DB object would return an instance of the
> > ooSQLiteStmt class that implements the methods. This allows the DB
> > object to have a bit of flexibility for determining what class to use
> > for a particular statement.
> 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