cwielenb/CNCF-Dataset huggingface dataset:
Project: Apache Spark (App Definition and Development / Streaming & Messaging)
File: CONTRIBUTING.md

Before opening a pull request, review the . It lists steps that are required before creating a PR. In particular, consider: Is the change important and ready enough to ask the community to spend time reviewing? Have you searched for existing, related JIRAs and pull requests? Is this a new feature that can stand alone as a ? Is the change being proposed clearly explained and motivated? When you contribute code, you affirm that the contribution is your original work and that you license the work to the project under the project's open source license. Whether or not you state this explicitly, by submitting any copyrighted material via pull request, email, or other means you agree to license the material under the project's open source license and warrant that you have the legal authority to do so.
Project: YugabyteDB (App Definition and Development / Database)
File: cockroachdb.md

title: Compare CockroachDB with YugabyteDB headerTitle: CockroachDB linkTitle: CockroachDB description: Compare CockroachDB with YugabyteDB in terms of database performance, PostgreSQL compatibility, and architecture. aliases: /comparisons/cockroachdb/ menu: preview_faq: parent: comparisons identifier: comparisons-cockroachdb weight: 1075 type: docs YugabyteDB's sharding, replication, and transactions architecture is similar to CockroachDB in that both are inspired by the . Additionally, both use Raft as the distributed consensus replication algorithm and RocksDB as the per-node storage engine. The following sections highlight the advantages and similarities YugabyteDB has when compared with CockroachDB. YugabyteDB beats CockroachDB in the context of multiple developer benefits including higher performance for large data sizes, better PostgreSQL compatibility, more flexible geo-distributed deployment options as well as higher data density. Following blogs highlight the architectural and implementation advantages that make these benefits possible. Following blogs highlight how YugabyteDB works as an open-source, cloud-native Spanner derivative similar to CockroachDB.
Project: YugabyteDB (App Definition and Development / Database)
File: hkeys.md

title: HKEYS linkTitle: HKEYS description: HKEYS menu: preview: parent: api-yedis weight: 2140 aliases: /preview/api/redis/hkeys /preview/api/yedis/hkeys type: docs `HKEYS key` This command fetches all fields of the hash that is associated with the given `key`. If the `key` does not exist, an empty list is returned. If the `key` is associated with non-hash data, an error is raised. Returns list of fields in the specified hash. ```sh $ HSET yugahash area1 "Africa" ``` ``` 1 ``` ```sh $ HSET yugahash area2 "America" ``` ``` 1 ``` ```sh $ HKEYS yugahash ``` ``` 1) "area1" 2) "area2" ``` , , , , , , , , , ,
Project: ClickHouse (App Definition and Development / Database)
File: v21.3.5.42-lts.md

sidebar_position: 1 sidebar_label: 2022 Backported in : Fix table function `clusterAllReplicas` returns wrong `shardnum`. close . (). Backported in : Remove unknown columns from joined table in where for queries to external database engines (MySQL, PostgreSQL). close , close (dup), close (dup). (). Backported in : Fix scalar subquery index analysis. This fixes , which was introduced in https://github.com/ClickHouse/ClickHouse/pull/18896 . (). Backported in : Better error handling and logging in WriteBufferFromS3. (). Backported in : In rare case, merge for `CollapsingMergeTree` may create granule with `index_granularity + 1` rows. Because of this, internal check, added in (affects 21.2 and 21.3), may fail with error `Incomplete granules are not allowed while blocks are granules size`. This error did not allow parts to merge. (). Backported in : Docker entrypoint: avoid chown of `.` in case when `LOG_PATH` is empty. Closes . (). Backported in : Disable `asyncsocketforremote`/`usehedged_requests` for buggy linux kernels. (). Backported in : Fix waiting for `OPTIMIZE` and `ALTER` queries for `ReplicatedMergeTree` table engines. Now the query will not hang when the table was detached or restarted. (). Backported in : Fix the background thread pool name. (). Backported in : Fix error `Invalid number of rows in Chunk` in `JOIN` with `TOTALS` and `arrayJoin`. Closes . (). Backported in : Fix docker entrypoint in case `http_port` is not in the config. (). Backported in : Fix query cancellation with `usehedgedrequests=0` and `asyncsocketfor_remote=1`. (). Backported in : Now clickhouse will not throw `LOGICAL_ERROR` exception when we try to mutate the already covered part. Fixes . (). Backported in : Do not limit HTTP chunk size. Fixes . (). Backported in : Buffer overflow (on read) was possible in `tokenbf_v1` full text index. The excessive bytes are not used but the read operation may lead to crash in rare cases. This closes . (). Backported in : Add (missing) memory accounting in parallel parsing routines. In previous versions OOM was possible when the resultset contains very large blocks of data. This closes . (). Backported in : Remove socket from epoll before cancelling packet receiver in HedgedConnections to prevent possible race. I hope it fixes . (). Backported in : Fix bug in partial merge join with `LowCardinality`. Close , close . (). Backported in : Fix deserialization of empty string without newline at end of TSV format. This closes . Possible workaround without version update: set `inputformatnullasdefault` to zero. It was zero in old versions. (). Backported in : Fix UB by unlocking the rwlock of the TinyLog from the same thread. (). Backported in : Avoid UB in Log engines for rwlock unlock due to unlock from another thread. (). Backported in : Try flush write buffer only if it is initialized. Fixes segfault when client closes connection very early . (). Backported in : Fix LOGICAL_ERROR for Log with nested types w/o columns in the SELECT clause. (). Manual backport of in 21.3 ().
Project: TDengine (App Definition and Development / Database)
File: feature-request.md

name: Feature Request about: Suggest an idea for this project title: '' labels: enhancement assignees: '' Is your feature request related to a problem? Please describe. A clear and concise description of what the circumstance is and what the associated problem is. Ex. I'm using TDengine for this use case: [...]. But I'm always frustrated when [...] Describe your desired behavior A clear and concise description of what you want to happen. Ex. I want TDengine to be able to do [...] when I try to do [...] with it. Describe your solutions/suggestions if you've any A clear and concise description of any solutions/suggestions to this problem or features you've considered. Additional context Add any other context or screenshots about the feature request here.
Project: SPIRE (Provisioning / Key Management)
File: plugin_agent_workloadattestor_docker.md

The `docker` plugin generates selectors based on docker labels for workloads calling the agent. It does so by retrieving the workload's container ID from its cgroup membership on Unix systems or Job Object names on Windows, then querying the docker daemon for the container's labels. | Configuration | Description | Default | |--||-| | dockersocketpath | The location of the docker daemon socket (Unix) | "unix:///var/run/docker.sock" | | docker_version | The API version of the docker daemon. If not specified | | | containeridcgroup_matchers | A list of patterns used to discover container IDs from cgroup entries (Unix) | | | dockerhost | The location of the Docker Engine API endpoint (Windows only) | "npipe:////./pipe/dockerengine" | | usenewcontainer_locator | If true, enables the new container locator algorithm that has support for cgroups v2 | false | | verbosecontainerlocator_logs | If true, enables verbose logging of mountinfo and cgroup information used to locate containers | false | A sample configuration: ```hcl WorkloadAttestor "docker" { plugin_data { } } ``` Since selectors are created dynamically based on the container's docker labels, there isn't a list of known selectors. Instead, each of the container's labels are used in creating the list of selectors. | Selector | Example | Description | |-|-|| | `docker:label` | `docker:label:com.example.name:foo` | The key:value pair of each of the container's labels. | | `docker:env` | `docker:env:VAR=val` | The raw string value of each of the container's environment variables. | | `docker:imageid` | `docker:imageid:77af4d6b9913` | The image id of the container. | The patterns provided should use the wildcard `*` matching token and `<id>` capture token to describe how a container id should be extracted from a cgroup entry. The given patterns MUST NOT be ambiguous and an error will be returned if multiple patterns can match the same input. Valid Example: ```hcl containeridcgroup_matchers = [ "/docker/<id>", "/my.slice//<id>/" ] ``` Invalid Example: ```hcl containeridcgroup_matchers = [ "/a/b/<id>", "/*/b/<id>" ] ``` Note: The pattern provided is not a regular expression. It is a simplified matching language that enforces a forward slash-delimited schema. If a workload container is started with `docker run --label com.example.name=foo [...]`, then workload registration would occur as: ```shell $ spire-server entry create \ -parentID spiffe://example.org/host \ -spiffeID spiffe://example.org/host/foo \ -selector docker:label:com.example.name:foo ``` You can compose multiple labels as selectors. ```shell $ spire-server entry create \ -parentID spiffe://example.org/host \ -spiffeID spiffe://example.org/host/foo \ -selector docker:label:com.example.name:foo -selector docker:label:com.example.cluster:prod ``` Example of an environment variable selector for the variable `ENVIRONMENT` matching a value of `prod`: ```shell $ spire-server entry create \ -parentID spiffe://example.org/host \ -spiffeID spiffe://example.org/host/foo \ -selector docker:env:ENVIRONMENT=prod ```
Project: ClickHouse (App Definition and Development / Database)
File: input.md

slug: /en/sql-reference/table-functions/input sidebar_position: 95 sidebar_label: input `input(structure)` - table function that allows effectively convert and insert data sent to the server with given structure to the table with another structure. `structure` - structure of data sent to the server in following format `'column1name column1type, column2name column2type, ...'`. For example, `'id UInt32, name String'`. This function can be used only in `INSERT SELECT` query and only once but otherwise behaves like ordinary table function (for example, it can be used in subquery, etc.). Data can be sent in any way like for ordinary `INSERT` query and passed in any available that must be specified in the end of query (unlike ordinary `INSERT SELECT`). The main feature of this function is that when server receives data from client it simultaneously converts it according to the list of expressions in the `SELECT` clause and inserts into the target table. Temporary table with all transferred data is not created. Examples Let the `test` table has the following structure `(a String, b String)` and data in `data.csv` has a different structure `(col1 String, col2 Date, col3 Int32)`. Query for insert data from the `data.csv` into the `test` table with simultaneous conversion looks like this: <!-- --> ``` bash $ cat data.csv | clickhouse-client --query="INSERT INTO test SELECT lower(col1), col3 * col3 FROM input('col1 String, col2 Date, col3 Int32') FORMAT CSV"; ``` If `data.csv` contains data of the same structure `test_structure` as the table `test` then these two queries are equal: <!-- --> ``` bash $ cat data.csv | clickhouse-client --query="INSERT INTO test FORMAT CSV" $ cat data.csv | clickhouse-client --query="INSERT INTO test SELECT * FROM input('test_structure') FORMAT CSV" ```
Project: StarRocks (App Definition and Development / Database)
File: count_if.md

displayed_sidebar: "English" Returns the number of records that meet the specified condition or `0` if no records satisfy the condition. This function does not support `DISTINCT`, for example `count_if(DISTINCT x)`. This function is internally transformed to `COUNT` + `IF`: Before: `COUNT_IF(x)` After: `COUNT(IF(x, 1, NULL))` ```Haskell COUNT_IF(condition) ``` `condition`: the condition that should evaluate to a BOOLEAN value. You can specify multiple count_if conditions in one SELECT statement. Returns a numeric value. If no records can be found, `0` is returned. This function ignores NULL values. Suppose there is a table named `testcountif`. ```Plain CREATE TABLE `testcountif` ( `v1` varchar(65533) NULL COMMENT "", `v2` varchar(65533) NULL COMMENT "", `v3` datetime NULL COMMENT "", `v4` int null ) ENGINE=OLAP DUPLICATE KEY(v1, v2, v3) PARTITION BY RANGE(`v3`) (PARTITION p20220418 VALUES [("2022-04-18 00:00:00"), ("2022-04-19 00:00:00")), PARTITION p20220419 VALUES [("2022-04-19 00:00:00"), ("2022-04-20 00:00:00")), PARTITION p20220420 VALUES [("2022-04-20 00:00:00"), ("2022-04-21 00:00:00")), PARTITION p20220421 VALUES [("2022-04-21 00:00:00"), ("2022-04-22 00:00:00"))) DISTRIBUTED BY HASH(`v1`) BUCKETS 4; INSERT INTO testcountif VALUES ('a','a', '2022-04-18 01:01:00', 1), ('a','b', '2022-04-18 02:01:00', NULL), ('a',NULL, '2022-04-18 02:05:00', 1), ('a','b', '2022-04-18 02:15:00', 3), ('a','b', '2022-04-18 03:15:00', 7), ('c',NULL, '2022-04-18 03:45:00', NULL), ('c',NULL, '2022-04-18 03:25:00', 2), ('c','a', '2022-04-18 03:27:00', 3); SELECT * FROM testcountif; +++++ | v1 | v2 | v3 | v4 | +++++ | a | NULL | 2022-04-18 02:05:00 | 1 | | a | a | 2022-04-18 01:01:00 | 1 | | a | b | 2022-04-18 02:01:00 | NULL | | a | b | 2022-04-18 02:15:00 | 3 | | a | b | 2022-04-18 03:15:00 | 7 | | c | NULL | 2022-04-18 03:25:00 | 2 | | c | NULL | 2022-04-18 03:45:00 | NULL | | c | a | 2022-04-18 03:27:00 | 3 | +++++ ``` Example 1: Count the number of rows in table `testcountif` where `v2` is null. ```Plain select countif(v2 is null) from testcount_if; +-+ | count_if(v2 IS NULL) | +-+ | 3 | +-+ ``` Example 2: Count the number of rows where `v1 >= v2 or v4 = 1` ```Plain select countif(v1 >= v2 or v4 = 1)from testcount_if; +-+ | count_if((v1 >= v2) OR (v4 = 1)) | +-+ | 3 | +-+ ``` Example 3: Specify multiple conditions. ```Plain select countif(v1 >= v2), countif(v1 >= v2 or v4 = 1), countif(v1 >= v2 and v4 = 1) from testcount_if; +--+-+--+ | countif(v1 >= v2) | countif((v1 >= v2) OR (v4 = 1)) | count_if((v1 >= v2) AND (v4 = 1)) | +--+-+--+ | 2 | 3 | 1 | ```
Project: YugabyteDB (App Definition and Development / Database)
File: detection.md

Searching for Identifiers =============================================================================== WARNING : This feature is at an early stage of development. As we've seen previously, this extension makes it very easy to [declare masking rules]. However, when you create an anonymization strategy, the hard part is scanning the database model to find which columns contains direct and indirect identifiers, and then decide how these identifiers should be masked. The extension provides a `detect()` function that will search for common identifier names based on a dictionary. For now, 2 dictionaries are available: english ('enUS') and french ('frFR'). By default, the english dictionary is used: ```sql tablename | columnname | identifiers_category | direct +-+-+-- customer | CreditCard | creditcard | t vendor | Firstname | firstname | t customer | firstname | firstname | t customer | id | account_id | t ``` The identifier categories are based on the [HIPAA classification]. Limitations This is an heuristic method in the sense that it may report usefull information, but it is based on a pragmatic approach that can lead to detection mistakes, especially: `false positive`: a column is reported as an identifier, but it is not. `false negative`: a column contains identifiers, but it is not reported The second one is of course more problematic. In any case, you should only consider this function as a helping tool, and acknowledge that you still need to review the entire database model in search of hidden identifiers. Contribute to the dictionnaries This detection tool is based on dictionnaries of identifiers. Currently these dictionnaries contain only a few entries. For instance, you can see the english identifier dictionary [here]. You can help us improve this feature by sending us a list of direct and indirect identifiers you have found in your own data models ! Send us an email at <contact@dalibo.com> or [open an issue] in the project.
Project: BOSH (Provisioning / Automation & Configuration)
File: README.md

](https://github.com/onsi/gomega/actions/workflows/test.yml) Jump straight to the to learn about Gomega, including a list of . If you have a question, comment, bug report, feature request, etc. please open a GitHub issue. Learn more about Ginkgo A collection of community matchers is available on the . Gomega is MIT-Licensed The `ConsistOf` matcher uses which is embedded in the source to simplify distribution. goraph has an MIT license. _ format are supported though, so new files work. Does not support base-60 floats. These are gone from YAML 1.2, and were actually never supported by this package as it's clearly a poor choice. and offers backwards compatibility with YAML 1.1 in some cases. 1.2, including support for anchors, tags, map merging, etc. Multi-document unmarshalling is not yet implemented, and base-60 floats from YAML 1.1 are purposefully not supported since they're a poor design and are gone in YAML 1.2. Installation and usage The import path for the package is gopkg.in/yaml.v3. To install it, run: go get gopkg.in/yaml.v3 API documentation -- If opened in a browser, the import path itself leads to the API documentation: API stability The package API for yaml v3 will remain stable as described in . License The yaml package is licensed under the MIT and Apache License 2.0 licenses. Please see the LICENSE file for details. Example ```Go package main import ( "fmt" "log" "gopkg.in/yaml.v3" ) var data = ` a: Easy! b: c: 2 d: [3, 4] ` // Note: struct fields must be public in order for unmarshal to // correctly populate the data. type T struct { A string B struct { RenamedC int `yaml:"c"` D []int `yaml:",flow"` } } func main() { t := T{} err := yaml.Unmarshal([]byte(data), &t) if err != nil { log.Fatalf("error: %v", err) } fmt.Printf(" t:\n%v\n\n", t) d, err := yaml.Marshal(&t) if err != nil { log.Fatalf("error: %v", err) } fmt.Printf(" t dump:\n%s\n\n", string(d)) m := make(map[interface{}]interface{}) err = yaml.Unmarshal([]byte(data), &m) if err != nil { log.Fatalf("error: %v", err) } fmt.Printf(" m:\n%v\n\n", m) d, err = yaml.Marshal(&m) if err != nil { log.Fatalf("error: %v", err) } fmt.Printf(" m dump:\n%s\n\n", string(d)) } ``` This example will generate the following output: ``` t: {Easy! {2 [3 4]}} t dump: a: Easy! b: c: 2 d: [3, 4] m: map[a:Easy! b:map[c:2 d:[3 4]]] m dump: a: Easy! b: c: 2 d: 3 4 ```
Project: BOSH (Provisioning / Automation & Configuration)
File: pull_request_workflow.md

Follow these steps to make a contribution to any of CF open source repositories: Fork the repository Update submodules (`git submodule update --init`) Create a feature branch (`git checkout -b better_bosh`) Run the tests to ensure that your local environment is working `bundle && bundle exec rake` (this may take a while) Make changes on the branch: Adding a feature Add tests for the new feature Make the tests pass Fixing a bug Add a test/tests which exercises the bug Fix the bug, making the tests pass Refactoring existing functionality Change the implementation Ensure that tests still pass If you find yourself changing tests after a refactor, consider refactoring the tests first See to determine which test suite to run. We expect you to run the unit tests. Push to your fork (`git push origin better_bosh`) and submit a pull request selecting `master` as the target branch We favor pull requests with very small, single commits with a single purpose. Your pull request is much more likely to be accepted if: Your pull request includes tests Your pull request is small and focused with a clear message that conveys the intent of your change.
Project: Operator Framework (App Definition and Development / Application Definition & Image Build)
File: v1.9.0.md

title: v1.9.0 weight: 998991000 There is currently no workaround other than running the operator as a pod in the cluster (where it will use the internal endpoint). The fix for this issue is currently blocked waiting on a fix to the apimachinery package. Once the upstream issue is merged then a proper fix will be done for ansible-operator. Work on this issue is being tracked here: https://github.com/operator-framework/operator-sdk/issues/4925 See for more details.
Project: Apache RocketMQ (App Definition and Development / Streaming & Messaging)
File: Example_CreateTopic.md

The `TopicMessageType` concept is introduced in RocketMQ 5.0, using the existing topic attribute feature to implement it. The topic is created by `mqadmin` tool declaring the `message.type` attribute. ```shell sh ./mqadmin updateTopic -n <nameserveraddress> -t <topicname> -c DefaultCluster sh ./mqadmin updateTopic -n <nameserveraddress> -t <topicname> -c DefaultCluster -a +message.type=NORMAL sh ./mqadmin updateTopic -n <nameserveraddress> -t <topicname> -c DefaultCluster -a +message.type=FIFO sh ./mqadmin updateTopic -n <nameserveraddress> -t <topicname> -c DefaultCluster -a +message.type=DELAY sh ./mqadmin updateTopic -n <nameserveraddress> -t <topicname> -c DefaultCluster -a +message.type=TRANSACTION ```