Hi Karl,
Just a question, I read all the warnings about how dependent LCF is on
postgres, but how much of this is really only about performance?
When I look at the code it seems like there is enough abstraction you
could add support for say, hsqldb or similar, even if its only for
testing
Hi Robert,
The dependency on postgresql is indeed mainly performance, as you say, although
there are a few kinds of queries that I am sure are somewhat
postgresql-specific at this point. These are mainly for the reporting
features, though. So your idea could work in a limited way.
Obviously
I have to admit I don't know much about the connectors but this sounds
like connectors heavily rely on postgresql. Karl, is it somehow
feasible to abstract this out to work with more than just postgresql
in production? Maybe making different test-backends pluggable would be
a win-win for tests and
On Mon, May 24, 2010 at 3:54 PM, karl.wri...@nokia.com wrote:
Obviously an end-to-end test would be the best, though. But something is
better than nothing.
Karl
I agree with this, but I think for unit tests, its best to have a very
simple new clean world for each test.
I think testing
There is an abstraction layer, and it is pretty solid, but (as you know),
database abstraction subtleties are pretty significant. The way a database
gathers statistics, for example, will determine how often you can get away with
doing an ANALYZE, and the sensitivity of the database's planner
I agree with this, but I think for unit tests, its best to have a very
simple new clean world for each test.
I think testing the postgres integration is not really unit tests at
all but something else, and we could make it a separate test module.
I have no problem with supporting both some
