On 2009-08-05, Paul Taylor <paul_t...@fastmail.fm> wrote: > Sam Mason wrote: >> On Wed, Aug 05, 2009 at 08:02:13AM -0400, Bill Moran wrote: >> >>> In response to Paul Taylor <paul_t...@fastmail.fm>: >>> >>>> this >>>> is an opensource project and to enable others to contribute easily it is >>>> much easier if they can download the code and run mvn package to compile >>>> and test. Once you start introducing external database setups, and >>>> database configs things can easily start going wrong, and you can't >>>> share databases when doing automated testing >>>> >>> Gonna have to disagree yet again. >>> >> >> Yup, I'm wondering about it as well. Surely if it's an open source >> project, people are going to have a database setup to run the thing with >> anyway--if only to test it? >> >> For build/test farms it's going to make it a bit more complex yes, but >> wouldn't it be easier to configure each machine separately (or write a >> set of scripts to do the common setup if you have 20+ test boxes!) than >> to bake in a large set of assumptions into your test scripts? >> >> > Ok, the original question was Postgres have an embedded mode. If it did > then everything could be contained with the application with no scripts > required AND no assumptions would be made about the database because the > same database would be running, this is the ideal scenario for me - and > I can't see any disadvantage in it.
write a virtual machine in java and run postgres in that :^) > If instead you have to run a database standalone, then you do hit > configurations problems, not only platform specific issues but also > people bloody mindness about creating databases with different names and > database users : whatever the documentation says which has to be > accounted for in tests. To pretend there are no issues with setting up a > database is unrealistic. send them a script that sets up the database and users, have the unit test first probe the database, pick names that are likly to be unique. in the rare event that there is a collision or other confilict (the user may have to setp setup a separate cluster for the test database. A "cluster" here is a software entitiy, not a real or virtual host nor group thereof. -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general