tracking db changes / comparing databases
От | aplst@xs4all.nl |
---|---|
Тема | tracking db changes / comparing databases |
Дата | |
Msg-id | 12975.62.4.75.26.1092838173.squirrel@webmail.xs4all.nl обсуждение исходный текст |
Ответы |
Re: tracking db changes / comparing databases
Re: tracking db changes / comparing databases |
Список | pgsql-admin |
Hello Group, This question has been brought up on various mailing lists, but without any definite answers if I am correct. I am working on a system that can be used to rapidly create simple to medium complex applications in PHP. It basically features a forms-system, a reporting system, and database-user-administration. Thus, when someone wants to create a simple (up to, say, 10 tables) application, (s)he can create the forms, create a little PHP-logic (may even be unnecesery), et voila. Something like access, but webbased and smaller in its feature-set. PostgreSQL is the only backend at this moment. On of the problems I'm having is keeping a development/test-session seperate from a production-system. I *Want* to have a seperate production-installation, develop on my test-installation and when a feature is complete and tested push the modifications to the production session. To do that I'd need to be able to produce: 1. data-definition changes 2. data added/modified to the tables You might be tempted to argue "If a users upgrades your software, he should create a new install and *you* should create a tool that converts his existing data" and you'd probably be right in the case of version-upgrades for users that only want to use "stable" releases, and upgrade only sporadically. But in the case of online colaboration (and for my own personal sessions) it would be very nice if new/changed data-definitions and data could be shared instantly (in stead of a full dump of the test-db). Last of all, I have a script that fills the database for the user at install-time. It asks a few questions and then fills the database using the user provided input. That script needs to be updated after new features are introduced, and thus I need to know what to add. Creating a new pg_dump for the entire database and script that one for each and every version would encompass and effort a lot greater than implementing the features. I did find an old pgdiff util on sourceforge, but development has has been idle for quite some time now (2 years IIRC). Don't recon it will support the most recent pg features. Would a standard diff work on the dumps? How do you share the data-definitions of your project(s) when they change (template1) ? Do you create all system-tables at pg_init runtime, and thus diff the C-source? I might be able to code a (not so large) project but am not sufficiently able in C. Perl would be okay. But I'd need a good plan to start from. Thank you for any thoughts, Sincerely, Arian Prins.
В списке pgsql-admin по дате отправления: