Re: Database Versioning with IDS

Ing. Melvin Perez Cedano wrote: > Thanks, Amgad for your comments! > > What you explained is one of the possible needs. Another one, my > major problem right now, is when you write commercial applications > that are delivered in releases with customers using different ones > and supporting them. I'm still not clear whether you are asking about database schema versioning, or using different versions of the RDBMS software. I think you must be asking about database schema versioning. > In the development environment you have to maintain source code > versioning and database versioning. But, I think that having an > ONCONFIG for each version is not a practical solution. No, in general, having a separate ONCONFIG file for each database is not sensible. > > Ing. Melvin Perez Cedano wrote: > > > I would like to get your opinions about having different > > > database versions for development or testing purposes in > > > an IDS environment. Being able to test the software on a different database from the production system is critical. You need to be able to handle (at least) an R&D database for development work, a QA database for testing the code, and the production database. Having a separate ONCONFIG for each is not feasible unless there's a separate, adequately powerful machine for each set of people needing a database. > > > Apparently, the database vendors are > > > not working in database version management, so we have to > > > find a way to maintain the change control, as we do with > > > source code files. Managing the schema changes is certainly important, especially when migrating a customer site from schema version 1 to schema version 2. > > > There are several needs that could involve in having several > > > version of the database. A version could be a database with > > > change at the schema level or at the data level. Most people would probably not regard a difference in the stored data as being a different version of the database (though it is tenable to argue that each change in the database creates a new version of the database). Changes in the schema, on the other hand, do create new versions of a given database schema. > > > Differently from SE, which create a directory for each database, > > > IDS doesn't allow to have several databases with the same name > > > within the same configuration (ONCONFIG). SE is remarkably convenient in this regard. However, all is not lost. > > > Even though we could rename a database, we couldn't use the > > > programs with that renamed database. I'm not clear which language you are using. However, with I4GL, D4GL or NewEra, it is possible to have the startup code select the required database at run time. I discussed this technique recently in the c.d.i forum -- 28th May 1998 under the subject "Re: SET UP TESTING DATABASE", according to DejaNews. > > > I think that Informix and > > > the other database vendors should provide a concept like synonym > > > applying to databases rather than tables, in such way that we > > > could refer to a database with a logical name within the > > > programs and just change the synonym/link to the desired > > > database. I use a similar concept with SE through UNIX symbolic > > > links. There are numerous problems with any such scheme, such as "How does Bill have a synonym XYZ pointing to database PQR at the same time as Joe has a synonym XYZ pointing to database ABC and the users of the production system have the synonym XYZ pointing to database JKL?" This is not insuperable, but it is symptomatic of the sorts of issues which would have to be addressed. > > > The first thing that comes to my mind in this issue is to have > > > as many ONCONFIG as desired databases versions. But, this > > > approach will be very resource consuming. Very! Especially once you get beyond two databases, but even two systems is an unwanted burden for many places. > > > Obviously, we'll need other tools, as script files to implement > > > a fully version control. I'm not sure what you're asking for or commenting on here. Schema migration is complicated, especially in a large database with fragmented tables. Things are not too painful with the in-place alter table, but that requires a sufficiently recent version of IDS. When you change the data type, this is usually not too much of a problem, especially if there's an automatic conversion between the old type and the new (eg from DECIMAL(8,2) to DECIMAL(10,2)). Adding a new column means you have to worry about the value that is added to the old columns (NULL), and what, if anything, to do about setting the value to something more meaningful. > > > I hope that my english had been fluently enough to let me > > > understood.. I'd write: "I hope that my English is fluent enough to let me be understood", or "I hope that my English is fluent enough for you to understand". Either way, your English is far better than my Spanish. > amgad wrote: > > From what I understood, you are talking about transaction-time > > temporal support in a database > > [...omitted because not directly relevant...] -- Jonathan Leffler (jleffler@informix.com, jleffler@earthlink.net) Guardian of DBD::Informix -- see http://www.perl.com/CPAN #include <disclaimer.h>