
Question:

    How feasible would it be to create this functionality in PostgreSQL:

One creates a test version of a database that initially consists of 
read-links to the production version of the same database.  Any code he/she 
then writes that reads from a table reads from the production database but 
any code that modifies data copies that table to the test database.

The benefits of this are obviously huge for IT shops that need to constantly 
work on data in test environments as similar as possible to the production 
environment.  

Usually, this is a very difficult aspect of one's work and represents a great 
deal of risk.   We always try to hard to ensure that what we migrate into 
production is going to work there the same as it did in test.  And we should 
not do testing in a production environment.

Such a feature would give PostgreSQL a major advantage over Oracle or DB2.

And some day when PostgreSQL is also distributable, it'll be ideal for the 
enterprise.  

Matthew

-- 
Anything that can be logically explained, can be programmed.

Fri, 14 Jun 2002 11:12:33 -0400
Matthew Tedder <matthew@tedder.com>
Big Test Environment Feature
Matthew Tedder wrote:

>Question:
>
>    How feasible would it be to create this functionality in PostgreSQL:
>
>One creates a test version of a database that initially consists of 
>read-links to the production version of the same database.  Any code he/she 
>then writes that reads from a table reads from the production database but 
>any code that modifies data copies that table to the test database.
>
>The benefits of this are obviously huge for IT shops that need to constantly 
>work on data in test environments as similar as possible to the production 
>environment.  
>
>Usually, this is a very difficult aspect of one's work and represents a great 
>deal of risk.   We always try to hard to ensure that what we migrate into 
>production is going to work there the same as it did in test.  And we should 
>not do testing in a production environment.
>
>Such a feature would give PostgreSQL a major advantage over Oracle or DB2.
>
>And some day when PostgreSQL is also distributable, it'll be ideal for the 
>enterprise.  
>
>Matthew
>
>  
>

Why wouldn't you use a pg_dump of the production database? Perhaps just 
a sampling every so often?

This sounds like a lot of unnecessary work for the engine. How about a 
seperate program which has
notify links to the source database and places updated data in the test db?

- Bill



Fri, 14 Jun 2002 13:41:07 -0700
Bill Cunningham <billc@ballydev.com>
Re: Big Test Environment Feature

Comments at appropriate places below..

On Friday 14 June 2002 04:41 pm, Bill Cunningham wrote:
> Matthew Tedder wrote:
> >Question:
> >
> >    How feasible would it be to create this functionality in PostgreSQL:
> >
> >One creates a test version of a database that initially consists of
> >read-links to the production version of the same database.  Any code
> > he/she then writes that reads from a table reads from the production
> > database but any code that modifies data copies that table to the test
> > database.
> >
> >The benefits of this are obviously huge for IT shops that need to
> > constantly work on data in test environments as similar as possible to
> > the production environment.
> >
> >Usually, this is a very difficult aspect of one's work and represents a
> > great deal of risk.   We always try to hard to ensure that what we
> > migrate into production is going to work there the same as it did in
> > test.  And we should not do testing in a production environment.
> >
> >Such a feature would give PostgreSQL a major advantage over Oracle or DB2.
> >
> >And some day when PostgreSQL is also distributable, it'll be ideal for the
> >enterprise.
> >
> >Matthew
>
> Why wouldn't you use a pg_dump of the production database? Perhaps just
> a sampling every so often?

That won't work nearly as well.  Obviously we can and often do dumps.  But 
when testing something that has to work in a production environment, we need 
to see what happens over a course of several day's time.  This is needed not 
only for testing of the specific code changed or added to a process, but also 
a test of how it integrations with a larger and more complex information flow 
system.  

>
> This sounds like a lot of unnecessary work for the engine. How about a
> seperate program which has
> notify links to the source database and places updated data in the test db?

Big unnecessary dumps and recreation of the data structures also 
unecissarilly use I/O resources.   The idea is to minimize that and 
easily/seemlessly create testing environments.  

Often, many programmer/analysis are working on different parts of the 
information system simultaneously each and every day.

Matthew

>
> - Bill
>
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 5: Have you checked our extensive FAQ?
>
> http://www.postgresql.org/users-lounge/docs/faq.html

-- 
Anything that can be logically explained, can be programmed.

Sat, 15 Jun 2002 12:37:07 -0400
Matthew Tedder <matthew@tedder.com>
Re: Big Test Environment Feature