On Fri, Jun 15, 2012 at 7:33 AM, Jeremy Nicoll - ml sourceforge
<[email protected]> wrote:
> Mark Miesfeld <[email protected]> wrote:
>
>> Here is an outline of the classes:
>> ...
>
> Something that catches my eye here isn't really a SQLite issue as such, but
> it seems to me that the implication of SQLite C structs having names which
> include a "3" is that future versions may be different.
>
> Do you have a mechanism in mind to allow future versions of ooSQLLite to use
> V4/5/6... structs and APIs?  How would a programmer dictate which set were
> to be used for a particular db?  Would it not be better to embed a "3" in
> the name of the class, whatever DLL (or whatever) it uses, and so on?

The ooSQLite package has entire SQLite database engine embedded inside
it.  So the programmer can not dictate which set of structs and APIs
it works with.  It works with the set it was built with.

If you had a database written / used with ooSQLite version, say:

ooSQLite: ooSQLite Version 1.0.0.7897 (64 bit)
          Built Jun 14 2012 16:47:20
          Copyright (c) RexxLA 2012-2012.
          All Rights Reserved.

Rexx:     Open Object Rexx Version 4.1.1

SQLite:   SQLite Library Version 3.7.13
          2012-06-11 02:05:22

and SQLite moved on to say, version 5.8.9, that was no longer
compatible with the database file format, then Rexx programmers would
have to decide whether they wanted to move on to ooSQLite 3.55.10,
which has SQLite version 5.8.9 in it, or not.

The Rexx programmer would be faced with the same choices as any other
SQLite user would be faced with.

The name of the structs in SQLite is of no consequence to the Rexx
programmer.  So, I don't really see a problem here.

--
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

Reply via email to