Mark Miesfeld <[email protected]> wrote: >On Fri, Jun 15, 2012 at 7:33 AM, Jeremy Nicoll - ml sourceforge ><[email protected]> wrote:
> > 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. I know; I haven't explained well enough... The problem is that "the set it was built with" isn't flexible enough once there are multiple versions of the engines. >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. On a home system that mightn't be a problem but suppose someone was using ooRexx on a commercial/ production system. They might be happy to use SQLite 5.8.9 for new apps / development, but need to keep running the version of ooSQLite that's based on 3.7.13 for legacy apps, and it's possible they might even have apps that accessed several dbs, some needing one version and some the other, eg while migrating specific dbs from one version of SQLite to another. Assuming that they'd only install ooRexx once, they'd need a way of making the older apps use one version of ooSQLite while other apps (using the same ooRexx) could use a newer version. Maybe this would only mean that they'd need to rename the supplied 'ooSQLite.cls' files to, say, 'ooSQLite3-7-13.cls' and 'ooSQLite5-8-9.cls' and ::require one or both of the specified files in their app. Obviously the binaries would need to be able to coexist too. But if the classnames do not include at least the "3" (and "5") would it actually be possible to make sure that the methods etc invoked by an object would come from the right .cls and binary files? >The Rexx programmer would be faced with the same choices as any other >SQLite user would be faced with. But in eg C you could surely compile an app with code using one or both of the sqlite3 and sqlite5 structs, depending on which was needed for which db, and then call the version-specific entry-point? >The name of the structs in SQLite is of no consequence to the Rexx >programmer. So, I don't really see a problem here. The name is only significant because the "3" in it gives a clue that the version of the engine used with a particular db may matter, and therefore that any user of SQLite may need to be able to choose which engine to use for a particular db or project. I was just suggesting that such a thing needs designed into the interface at the start, so that any business user using SQLite and ooRexx can work around that problem. -- Jeremy Nicoll - my opinions are my own ------------------------------------------------------------------------------ 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
