On 12/10/21 14:41, Pavel Cisar wrote:
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?
I see no big use in full support of v.3. Requested UDR is trivial but I
highly displike requirement of keeping it in std distro of firebird.
Firebird-Devel mailing list, web interface at
https://lists.sourceforge.net/lists/listinfo/firebird-devel
