In DBT YAML file such as dbt_project.yml, what is + or - sign of the element?
models:
# Be sure to namespace your model configs to your project name
dbt_labs:
# This configures models found in models/events/
events:
+enabled: true # <--- What is the meaning of +?
+materialized: view # <--- What is the meaning of +?
# This configures models found in models/events/base
# These models will be ephemeral, as the config above is overridden
base:
+materialized: ephemeral # <--- What is the meaning of +?
"-" is standard YAML syntax, indicating a "list" item: docs.ansible.com > YAML Basisc
"+" is DBT-specific, indicating a sub-category like "+indexes", "+tags". It's just a DBT convention. docs.getdbt.com > Materialize Configs.
The plus is mentioned in the docs:
"The + prefix is a dbt syntax feature, introduced in dbt v0.17.0, which helps disambiguate between resource paths and configs in dbt_project.yml files."
See:
https://docs.getdbt.com/reference/resource-configs/plus-prefix
Related
In the ec2 instance module I have couple of security groups one from variable and other created in the module. I have a situation where new security groups are to be added in the terraform file which are sourcing from this module.
To be able to concat a new list I want to convert existing format1 into an explicit list which I am not able to do. How can I achieve this?
resource "aws_instance" "instance" {
//...
# (current)format1: Works
vpc_security_group_ids = ["${aws_security_group.secGrp_1.id}", "${var.secGrp_2}"]
# format2: Doesn't work
vpc_security_group_ids = "${list(aws_security_group.secGrp_1.id, var.secGrp_2)}"
# format3: Works
vpc_security_group_ids = "${list(var.secGrp_2)}"
# format3: Doesn't works
vpc_security_group_ids = "${list(tostring(aws_security_group.secGrp_1.id), var.secGrp_2)}"
Format2 fails with: "vpc_security_group_ids: should be a list".
I suspect the secGrp1 id is not being recognized as a string in this representation.
Format4 fails with: "unknown function called: tostring in:
${(list(tostring(aws_security_group.secGrp_1.id), var.secGrp_2))}"
P.S: The Terraform version we are using is 0.11.x
Terraform v0.11 is unable to represent partially-unknown lists during expression evaluation. On initial create, aws_security_group.secGrp_1.id will be unknown and therefore passing it to the list function will produce a wholly-unknown value, which isn't valid to use as the value for a list argument.
This is one of the various expression-language-related problems that Terraform v0.12 addressed. In Terraform v0.12 the following expression equivalent to your second one should work:
vpc_security_group_ids = [
aws_security_group.secGrp_1.id,
var.secGrp_2,
]
To get your intended result with Terraform v0.11 will require applying this configuration in two stages, so that Terraform can know the value of aws_security_group.secGrp_1.id before evaluating aws_instance.instance:
terraform apply -target=aws_security_group.secGrp_1 to apply only that resource and the other resources it depends on.
Then just terraform apply to apply everything else, including aws_instance.instance.
Under the "Nesting Variables" section in Codeigniter4 site:
"To save on typing, you can reuse variables that you’ve already specified in the file by wrapping the variable name within ${...}"
link to CI nesting Variables section
example in the documentation:
BASE_DIR="/var/webroot/project-root"
CACHE_DIR="${BASE_DIR}/cache"
TMP_DIR="${BASE_DIR}/tmp"
I was trying to use the following
app.baseURL = 'http://localhost:8080/'
google.redirect = ${app.baseURL}Google
However, it's assigning it as a literal when print_r($_ENV)
[google.redirect] => ${app.baseURL}Google
I've tried using non-namespaced keys including BASE_DIR (per the example) and it keeps printing as a literal.
What's strange - When I use the following:
CI_ENVIRONMENT = development
google.redirect = ${CI_ENVIRONMENT}Google
The result when print_r is:
[CI_ENVIRONMENT] => development
[google.redirect] => developmentGoogle
My question is - What am I doing incorrectly and/or how should these be set/used correctly?
According to the documentation, I should be able to use any key within the .env file that was already assigned using
${somekeyinthisfile}
After a bit of looking, there is a more recent file up at
https://github.com/codeigniter4/CodeIgniter4/blob/develop/system/Config/DotEnv.php
with all the "other" changes...
This was a Bug Fix. So get that file and you will be good to go.
I am pretty sure that the intention wasn't to allow app.xxx settings to be used as variables as the documentation clearly shows, by not
showing them being used. ( yes its 6am now ...)
BUT it is your code to do with as you please...So if you want to use app.xxx as variables...
The Only Thing missing is the DOT (.) in the regex
If you look on Line 272 - system/Config/DotEnv.php inside method resolveNestedVariables() and add a . (dot) into the regex, that will make all your app.things work.
$value = preg_replace_callback(
'/\${([a-zA-Z0-9_.]+)}/',
function ($matchedPatterns) use ($loader) {
I have added a dot (.) at the end of the [a-zA-Z0-9_
So
'/\${([a-zA-Z0-9_]+)}/',
becomes
'/\${([a-zA-Z0-9_.]+)}/',
If Im using a jinja template I can override properties via command line like this:
--properties zone:us-central1-a,machineType:n1-standard-1,image:debian-9
But I see no documentation or examples for doing this with nested properties like labels or environmentVariables for example:
resources:
- name: resource-name
type: 'gcp-types/cloudfunctions-v1:projects.locations.functions'
properties:
labels:
testlabel1: testlabel1value
testlabel2: testlabel2value
environmentVariables:
TEST: 'zzzzzzzzz'
How do set properties like these? this does not work: --properties labels:testlabel1:newvalue
The short answer here is that the --properties flag is not meant to pass property values to the template. A template cannot run without a configuration file, the --properties flag is meant to replace the config file. Each parameter you pass is the same as listing them in a config file.
Essentially using --template my-template.py --properties zone:us-central1-f is the equivalent of running --config myConfig.yaml where the YAML is defined as such:
imports:
- path: my-template.py
resources:
- name: some-resource
type: my-temaplte.py
properties:
zone: us-central1-f
The --properties flag is not meant to pass raw data to replace non-variables.
Although this does not directly answer your question, you shouldn't normally need to define nested values in the flag. Your template will generally call on direct variables taken from the object properties.
despite this, I did try some tests, and as far as I can tell, you can't do this.
After some trial and error I managed to pass an object via command line like this:
--properties ^~^labels:{'testlabel1: testlabel1value','testlabel2: testlabel2value'}~environmentVariables:{'TEST: zzzzzzzzz'}
This sequence of symbols ^~^ is how you can change delimiter. You have to put it at the beginning of your properties. More info about escaping you can find here.
I put single apostrophe over single key value pair because we need that space between key and value. Otherwise it's interpereted as key with null value.
If you're using Bash shell you should also escape {,} symbols.
I'm trying to debug the service wrapper for Neo4j Community Server and no matter what I've tried there is never a log file generated. Does the Windows-Wrapper actually generate log entries? The documentation references the neo4j-wrapper but not the windows-wrapper.
OS: Windows 8.1 or Windows Server 2012 R2
Neo4j: 2.1.4 or 2.1.7 Community
I changed the logging levels to ALL everywhere I could and the only log files generated are /data/neo4j.0.0.log which seems to only contain information about the HTTP endpoint and /data/graph.db/messages.log which has no references to the wrapper. I expected to find a log file called /data/log/windows-wrapper.0.0.log
Any ideas on what I've done wrong?
windows-wrapper.logging.properties
# Properties file which configures the operation of the JDK logging facility.
# The system will look for this config file, first using a System property
# specified at startup:
#
# >java -Djava.util.logging.config.file=myLoggingConfigFilePath
#
# If this property is not specified, then the config file is retrieved from its
# default location at:
# JDK_HOME/jre/lib/logging.properties
# Global logging properties.
# ------------------------------------------
# The set of handlers to be loaded upon startup.
# Comma-separated list of class names.
# (? LogManager docs say no comma here, but JDK example has comma.)
#handlers=java.util.logging.FileHandler, java.util.logging.ConsoleHandler
handlers=java.util.logging.FileHandler
# Default global logging level.
# Loggers and Handlers may override this level
# SERVERE, INFO, FINE, FINEST
.level=ALL
# Loggers
# ------------------------------------------
# Loggers are usually attached to packages.
# Here, the level for each package is specified.
# The global level is used by default, so levels specified here simply act as
# an override.
org.neo4j.server.level=ALL
# Handlers
# -----------------------------------------
# --- ConsoleHandler ---
# Override of global logging level
java.util.logging.ConsoleHandler.level=ALL
java.util.logging.ConsoleHandler.formatter=org.neo4j.server.logging.SimpleConsoleFormatter
java.util.logging.ConsoleHandler.filter=org.neo4j.server.logging.NeoLogFilter
# --- FileHandler ---
# Override of global logging level
java.util.logging.FileHandler.level=ALL
# Naming style for the output file (the output file is placed in the directory
# defined by the "user.home" System property):
# "/" the local pathname separator
# "%t" the system temporary directory
# "%h" the value of the "user.home" system property
# "%g" the generation number to distinguish rotated logs
# "%u" a unique number to resolve conflicts
# "%%" translates to a single percent sign "%"
java.util.logging.FileHandler.pattern=data/log/windows-wrapper.%u.%g.log
# Specifies whether the FileHandler should append onto any existing files
# (defaults to false):
java.util.logging.FileHandler.append=true
# Limiting size of output file in bytes (10M):
java.util.logging.FileHandler.limit=10000000
# Number of output files to cycle through, by appending an integer to the base
# file name:
java.util.logging.FileHandler.count=10
# The name of the character set encoding to use (defaults to the default
# platform encoding):
#java.util.logging.FileHandler.encoding=
# Style of output (Simple or XML):
java.util.logging.FileHandler.formatter=java.util.logging.SimpleFormatter
logging.properties
# Properties file which configures the operation of the JDK
# logging facility.
# The system will look for this config file, first using
# a System property specified at startup:
#
# >java -Djava.util.logging.config.file=myLoggingConfigFilePath
#
# If this property is not specified, then the config file is
# retrieved from its default location at:
# JDK_HOME/jre/lib/logging.properties
# Global logging properties.
# ------------------------------------------
# The set of handlers to be loaded upon startup.
# Comma-separated list of class names.
# (? LogManager docs say no comma here, but JDK example has comma.)
handlers=java.util.logging.FileHandler, java.util.logging.ConsoleHandler
#handlers=java.util.logging.ConsoleHandler
# Default global logging level.
# Loggers and Handlers may override this level
# SEVERE, INFO, FINE, FINEST
.level=ALL
# Loggers
# ------------------------------------------
# Loggers are usually attached to packages.
# Here, the level for each package is specified.
# The global level is used by default, so levels specified here simply act as
# an override.
org.neo4j.server.level=ALL
# Handlers
# -----------------------------------------
# --- ConsoleHandler ---
# Override of global logging level
java.util.logging.ConsoleHandler.level=ALL
java.util.logging.ConsoleHandler.formatter=org.neo4j.server.logging.SimpleConsoleFormatter
#java.util.logging.ConsoleHandler.filter=org.neo4j.server.logging.NeoLogFilter
# --- FileHandler ---
# Override of global logging level
java.util.logging.FileHandler.level=ALL
# Naming style for the output file (the output file is placed in the directory
# defined by the "user.home" System property):
# "/" the local pathname separator
# "%t" the system temporary directory
# "%h" the value of the "user.home" system property
# "%g" the generation number to distinguish rotated logs
# "%u" a unique number to resolve conflicts
# "%%" translates to a single percent sign "%"
java.util.logging.FileHandler.pattern=data/log/neo4j.%u.%g.log
# Specifies whether the FileHandler should append onto any existing files
# (defaults to false):
java.util.logging.FileHandler.append=true
# Limiting size of output file in bytes (10M):
java.util.logging.FileHandler.limit=10000000
# Number of output files to cycle through, by appending an integer to the base
# file name:
java.util.logging.FileHandler.count=10
# The name of the character set encoding to use (defaults to the default
# platform encoding):
#java.util.logging.FileHandler.encoding=
# Style of output (Simple or XML):
java.util.logging.FileHandler.formatter=java.util.logging.SimpleFormatter
Since I was the last person to make changes to that particular part of the codebase, I'll attempt an awswer: yes, we do do logging. Here, for example: https://github.com/neo4j/windows-wrapper/blob/master/src/main/java/org/neo4j/wrapper/NeoServiceWrapper.java#L49-60
That is only in the case where you launch it as a console app though, it seems. And I am not sure if the library we use does logging of it's own. And I have to admit that last I looked at this I didn't notice whether logging was indeed working or not.
So, I have not got any concrete advice for you at the moment. I'll make sure to make a note in the backlog to go over this. Meanwhile if you get a breakthrough let us know!
Lasse
How can I check if / else in yaml file.
like:
if %{attribute}
attributes:
shipping_comment: Shipping comment / Instructions
else
attributes:
shipping_date: Date
YAML is a data serialisation language, so it's not meant to contain if/else style executable statements: that's the responsibility of the programming language you're using.
A simple example in Ruby to determine which config string from a YAML file to output could be defining your YAML config file as follows:
data.yml
attributes:
shipping_comment: Shipping comment / Instructions
shipping_date: Date
Then, in your program, read the file in and run the conditional there:
shipping.rb
#!/usr/bin/env ruby
require 'yaml'
config = YAML.load_file('data.yml')
attribute = true # your attribute to check here
if attribute
puts config['attributes']['shipping_comment']
else
puts config['attributes']['shipping_date']
end
Out of the box .yaml files won't include any conditional logic, as Paul Fioravanti says:
YAML is a data serialisation language, so it's not meant to contain if/else style executable statements: that's the responsibility of the programming language you're using.
However, there are some cases, such as Infrastructure as Code where you might not have the luxury of Paul's solution. In these cases, most decent Infrastructure tools provide an inbuilt way of achieving conditional logic.
Since it appears that infra is not the area you're looking in, I won't go into detail on how to write each tools solution, but for anyone that end's up here like I did, docs such as these helped me and may prove useful for you:
Ansible
CloudFormation
This is a little late for the original poster, but may be of use to others: The Azure implementation of the YAML parser does support conditional checks. For example, the following YAML in an azure-pipeline.yml:
#azure-pipeline.yml
parameters:
- name: testCondition
displayName: 'Use experimental build process?'
type: boolean
default: true
steps:
- ${{ if eq(parameters.testCondition, true) }}:
- bash: echo 'true'
- ${{ if not(eq(parameters.testCondition, true)) }}:
- bash: echo 'false'
will evaluate the value of the testCondition parameter. When run, the bash task will echo "true", something like this: