launchpad-dev team mailing list archive
-
launchpad-dev team
-
Mailing list archive
-
Message #04883
Re: how to use feature flags
-
To:
launchpad-dev@xxxxxxxxxxxxxxxxxxx
-
From:
Aaron Bentley <aaron@xxxxxxxxxxxxx>
-
Date:
Wed, 29 Sep 2010 14:25:27 -0400
-
In-reply-to:
<AANLkTikApCyvjKob4xsGvXc+gJ12tOmsGSz=S_1VY+SR@mail.gmail.com>
-
User-agent:
Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.9) Gecko/20100922 Thunderbird/3.1.4
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 09/21/2010 06:09 PM, Robert Collins wrote:
> yes, see the existing tests that do it ;) I suggest the memcache ones
> as an example. There is an XXX there that needs fixing too.
You mean this?
>>> ignore = getFeatureStore().add(FeatureFlag(
... scope=u'default', flag=u'memcache', value=u'disabled',
... priority=1))
>>> empty_request = LaunchpadTestRequest()
>>> per_thread.features = FeatureController(
... ScopesFromRequest(empty_request).lookup)
I think there's a lot of room for improvement here. If feature flags
are meant to be pervasive, I think we should be able to depend on their
existence in tests, not need to create them explicitly-- otherwise,
we'll get test failures because the FeatureController hasn't been
initialized. (Or worse, we'll accidentally leak FeatureControllers into
other tests.) If performance is an issue, we can make a
LazyFeatureController that won't cost anything unless we use a FeatureFlag.
There's also a significant disconnect between how flags are queried and
how they are set. Since they are queried via FeatureController, I
searched in vain for a method to set them there.
Also, features.getFeatureFlag is a function, not a method, so it should
not have a camelCase name.
Aaron
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAkyjhJcACgkQ0F+nu1YWqI3k9QCfbILJTc+ny/BVsn2cHCchlxjV
3OEAn1sgKvJVrObQWyHFzfGXTs7ZSMxa
=1OBY
-----END PGP SIGNATURE-----
Follow ups
References