Examples: query, "exact match", wildcard*, wild?ard, wild*rd
Fuzzy search: cake~ (finds cakes, bake)
Term boost: "red velvet"^4, chocolate^2
Field grouping: tags:(+work -"fun-stuff")
Escape special characters +-&|!(){}[]^"~*?:\ - e.g. \+ \* \!
Range search: properties.timestamp:[1587729413488 TO *] (inclusive), properties.title:{A TO Z}(excluding A and Z)
Combinations: chocolate AND vanilla, chocolate OR vanilla, (chocolate OR vanilla) NOT "vanilla pudding"
Field search: properties.title:"The Title" AND text
 
Answered
Can I Create Runtime Configuration Options/Values (accessible via Q2 Central)?

Hello,

The Online Form Guide mentions configuration values stored in the database:

Don’t forget: the values we add to the RequestHandler are just defaults for the Caliper SDK to create when the relevant commands are run. At runtime, the values will be pulled from the settings.py file for Required Configurations, or the database for wedge address configs.

This sounds like a perfect solution to some runtime settings that we would like to be able to enable or disable on the fly without a new deployment/code change (like whether to use caching or not, etc.). My question is, how would our FI go about updating these wedge address config database values? Is this something that can be done through Q2 central? Or would this require a support ticket? We would like a way to change these options on the fly for testing, especially.

Thank you in advance for the help!

0
Posted 5 years ago
pic
⠿More
Dan Collins
99 × 4
Report
Votes Newest

Answers

Currently the only way to update wedge address configs is through creating a support ticket. This does change the values at runtime.

For testing, you can change the values in your dev environment either by stopping the server, and changing a value and then restarting it. You should be able to do that at any point and it should create the same effect as long as you aren't restarting the server in the middle of a call.

How often are you planning on needing to update the wedge address configs?

1
Posted 5 years ago
pic
⠿More
Trey Teter
124 × 2 Administrator
0

Hi Trey, thank you for the quick response! The specific example of what we were after this time around would be having the ability in both staging and production to be able to "flip a flag" to either enable or disable caching for core query calls.

— Dan Collins   5 years ago
0

So, the frequency would potentially be semi-frequent depending on the need to test live core calls for testing, etc.

— Dan Collins   5 years ago
0

Hmm, I see. This is an excellent technical question. There is a lot of different problems to this exact question. Ideally, Staging is just to confirm things works as intended, testing of any sort should really happen in the dev environment.

— Trey Teter   5 years ago
0

Of course you can't really directly test Core calls in the dev environment, so instead, every call should be mocked to simulate what would be happening in Staging and production. If you wanted to do it the proper way that would be how I recommend doing it

— Trey Teter   5 years ago
0

I would put a "feature flag" in the wedge address config to be able to turn the feature on and off though for sure. Which it sounds like you have done. Of course this is just the proper development method.

— Trey Teter   5 years ago
Show more results postcomments
Report
Write your answer
100 Views
1 Answer
5 years ago
5 years ago
Tags
Answered database
runtime-configuration
wedge-address-configs