On Sat, Jun 2, 2012 at 5:28 AM, Rick McGuire <[email protected]> wrote:
> 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
constants:
::class 'ooSQL' public
Each constant is named the same as the SQLITE_x constant, minus the SQLITE_
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 using
>
> 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
[email protected]
https://lists.sourceforge.net/lists/listinfo/oorexx-devel
