Sam Mason wrote:
> On Wed, Aug 05, 2009 at 08:02:13AM -0400, Bill Moran wrote:
>
>> In response to Paul Taylor <paul_t100@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.
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.
Alternatively , use an embedded database of a different type but then
the syntax would be different plus many other parts of the database
which may/may not be relevant.
So neither solution is great, for more complex applications would have
to go with standalone database, but for simpler database interactions
the second option is viable.
Paul
