Hi all,
our test suite contains many tests that depend on specific server
configuration settings (mostly related to security, encryption, pools,
timeouts, transactions etc.). As these configuration requirements may
contradict each other, it's not possible to create single firebird.conf
that would satisfy all tests. While the number of such tests is small,
it's not marginal either. Now such tests fail (in best case) when
requirement is not met, which spoils the QA run results when whole suite
is run, or they have to be explicitly excluded which further complicates
the management of QA runs.
As it's hard for us to automatically change the firebird.conf and
restart the server quickly and reliably on all platforms, we couldn't
run each test with its own engine configuration specification. It would
also complicate automated testing on our build systems. So, instead this
I'd like add the ability to check tested engine configuration to our QA
tool set (pytest plugin), so tests could be automatically skipped if
their requirement is not satisfied.
On FB v4+ it's easy, thanks to RDB$CONFIG pseudo-table. However, on v3
it's not that simple. I thought that I could use
iMaster.get_config_manager() -> iConfigManager.get_firebird_conf() ->
iFirebirdConf for that, but it does not work from client side (reads
client config, so it works only with embedded). To make it work for
remote access, we would need UDR that (according to Vlad) should be able
to query master interface and get current config. We don't need anything
complicated, just one function that would get configuration option name
(string) and returns it's value (NULL or string [VARCHAR?]).
But here we run into two problems:
1) Although it should be simple UDR, it's out of my area of expertise
and I'm not able to create it myself.
2) It should be part of Firebird 3 build process and stored in
/plugins/udr like udrcpp_example is, so it could be used by QA.
Alternatively, we can simply skip such checks for v3 and skip these
tests unless some env variable would have certain value, which could be
also workable solution (although less convenient). In fact, if v5 would
be really released next year (rendering v3 obsolete), it could be the
simplest solution.
What is your opinion? Which route we should go?
best regards
Pavel
Firebird-Devel mailing list, web interface at
https://lists.sourceforge.net/lists/listinfo/firebird-devel
