cwielenb/CNCF-Dataset huggingface dataset:
Project: ClickHouse (App Definition and Development / Database)
File: aggregatefunction.md

slug: /en/sql-reference/data-types/aggregatefunction sidebar_position: 46 sidebar_label: AggregateFunction Aggregate functions can have an implementation-defined intermediate state that can be serialized to an `AggregateFunction()` data type and stored in a table, usually, by means of . The common way to produce an aggregate function state is by calling the aggregate function with the `-State` suffix. To get the final result of aggregation in the future, you must use the same aggregate function with the `-Merge`suffix. `AggregateFunction(name, typesofarguments)` parametric data type. Parameters Name of the aggregate function. If the function is parametric, specify its parameters too. Types of the aggregate function arguments. Example ``` sql CREATE TABLE t ( column1 AggregateFunction(uniq, UInt64), column2 AggregateFunction(anyIf, String, UInt8), column3 AggregateFunction(quantiles(0.5, 0.9), UInt64) ) ENGINE = ... ``` , anyIf (+) and are the aggregate functions supported in ClickHouse. To insert data, use `INSERT SELECT` with aggregate `-State`- functions. Function examples ``` sql uniqState(UserID) quantilesState(0.5, 0.9)(SendTiming) ``` In contrast to the corresponding functions `uniq` and `quantiles`, `-State`- functions return the state, instead of the final value. In other words, they return a value of `AggregateFunction` type. In the results of `SELECT` query, the values of `AggregateFunction` type have implementation-specific binary representation for all of the ClickHouse output formats. If dump data into, for example, `TabSeparated` format with `SELECT` query, then this dump can be loaded back using `INSERT` query. When selecting data from `AggregatingMergeTree` table, use `GROUP BY` clause and the same aggregate functions as when inserting data, but using `-Merge`suffix. An aggregate function with `-Merge` suffix takes a set of states, combines them, and returns the result of complete data aggregation. For example, the following two queries return the same result: ``` sql SELECT uniq(UserID) FROM table SELECT uniqMerge(state) FROM (SELECT uniqState(UserID) AS state FROM table GROUP BY RegionID) ``` See engine description. Blog:
Project: GraphScope (App Definition and Development / Database)
File: gs.md

`gsctl` is a command-line utility for GraphScope. It is shipped with `graphscope-client` and provides a set of functionalities to make it easy to use GraphScope. These functionalities include building and testing binaries, managing sessions and resources, and more. Since it is shipped with python package `graphscope-client`, the `gsctl` command will be available in your terminal after installing GraphScope: ```bash $ pip3 install graphscope-client ``` In some cases, such as development on `gsctl`, you may want to build it from source. To do this, navigate to the directory where the source code is located and run the following command: ```bash $ cd REPO_HOME/python $ pip3 install --editable . ``` This will install `gsctl` in an editable mode, which means that any changes you make to the source code will be reflected in the installed version of `gsctl`. With `gsctl`, you can do the following things. Always remember to use `--help` on a command to get more information. The `gsctl` command-line utility supports two modes of operation: utility scripts and client/server mode. You can switch between these modes using the `gsctl connect` and `gsctl close` commands. Default, the `gsctl` provide helper functions and utilities that can be run using gsctl alone. `gsctl` acts as the command-line entrypoint for GraphScope. Some examples of utility scripts are: `gsctl install-deps`, install dependencies for building GraphScope. `gsctl make`, build GraphScope executable binaries and artifacts. `gsctl make-image`, build GraphScope docker images. `gsctl test`, trigger test suites. `gsctl connect`, connect to the launched coordinator by ~/.gs/config. `gsctl close`, Close the connection from the coordinator. `gsctl flexbuild`, Build docker image for Interactive, Insight product. To switch to the client/server mode, use the `gsctl connect` command. By default, this command connects gsctl to a launched coordinator using the configuration file located at `${HOME}/.gsctl`; If `--coordinator-endpoint` parameter is specified, it will treat it as the current context and override the configuration file. Once connected, you can use `gsctl` to communicate with the coordinator which serves the specific Flex product behind it. In `gsctl`, you can run commands on a global scope or a local scope. When you connect to a coordinator, you are in the global scope. To change to local scope of a graph, run the `gsctl use GRAPH <graph_identifier>` command. You can find the graph identifier with `gsctl ls` command. ```bash $ gsctl use GRAPH modern_graph Using GRAPH modern_graph ``` To switch back to the global scope. run `gsctl use GLOBAL` command. ```bash $ gsctl use GLOBAL Using GLOBAL ``` Different scopes have different commands. Always remember to use `--help` on a command to get more information. To disconnect from the coordinator and switch back to the utility scripts mode, you can use the `gsctl close` command. This command closes the connection from the coordinator and allows you to use `gsctl` as a standalone utility again.
Project: Chef InSpec (Provisioning / Security & Compliance)
File: xml.md

+++ title = "xml resource" draft = false gh_repo = "inspec" platform = "os" [menu] [menu.inspec] title = "xml" identifier = "inspec/resources/os/xml.md xml resource" parent = "inspec/resources/os" +++ Use the `xml` Chef InSpec audit resource to test data in an XML file. {{< readfile file="content/inspec/reusable/md/inspec_installation.md" >}} This resource first became available in v1.37.6 of InSpec. An `xml` resource block declares the data to be tested. Assume the following XML file: <root> <name>hello</name> <meta> <creator>John Doe</creator> </meta> <array> <element>one</element> <element>two</element> </array> <array> <element value="one"></element> <element value="two"></element> </array> </root> This file can be queried for elements using: describe xml('/path/to/name.xml') do its('root/name') { should eq ['hello'] } its('root/meta/creator') { should eq ['John Doe'] } its('root/array[2]/element') { should eq ['two'] } end This file can be queried for attributes using: describe xml('/path/to/name.xml') do its('root/array[2]/element/@value') { should eq ['one', 'two'] } its('root/array[2]/element/attribute::value') { should eq ['one', 'two'] } its('root/array[2]/element[2]/attribute::value') { should eq ['two'] } its('count(//*)') { should eq [42] } its('boolean(root/array[2]/element[2]/@valid)') { should eq [false] } end where `root/name` and `root/array[2]/element/@value` is an XPath expression `should eq ['foo']` tests a value of `root/name` as read from an XML file versus the value declared in the test In the above example, you see the use of `@` and `attribute::` which are both methods of fetching attributes. In the event the path contains an element which contains periods, the alternate syntax can be used: its(['root/name.with.a.period']) { should cmp 'somanydots' } The following examples show how to use this Chef InSpec audit resource. describe xml('applicationHost.config') do its(['configuration/system.applicationHost/applicationPools/add@name']) { should contain('my_pool') } end describe xml('applicationHost.sites') do its('site[@name="Default Web Site"]/application/virtualDirectory/@path') { should eq ['/'] } end {{< readfile file="content/inspec/reusable/md/inspecmatcherslink.md" >}} This resource has the following special matchers. The `name` matcher tests the value of `name` as read from a JSON file versus the value declared in the test: its('name') { should eq 'foo' }
Project: CockroachDB (App Definition and Development / Database)
File: feature_request.md

name: 'Feature request' title: '' about: 'Suggest an idea for this project' labels: 'C-enhancement' assignees: '' Is your feature request related to a problem? Please describe. A clear and concise description of what the problem is. Ex. I'm always frustrated when [...] Describe the solution you'd like A clear and concise description of what you want to happen. Describe alternatives you've considered A clear and concise description of any alternative solutions or features you've considered. Additional context Add any other context or screenshots about the feature request here.
Project: YugabyteDB (App Definition and Development / Database)
File: type-date.md

title: The date data type [YSQL] headerTitle: The date data type linkTitle: Date data type description: The semantics of the date data type. [YSQL] menu: v2.18: identifier: type-date parent: date-time-data-types-semantics weight: 10 type: docs Values whose data type is date represent the date component of some moment (the year, the month, and the day) in the "local" (a.k.a. "wall-clock") regime. Date values know nothing about timezones, and represent the date at some unspecified location. You can picture a date value as the number of days (or microseconds, if you prefer) to the start of the day in question from the start of some epochwhich number is then mapped using the to a date in the familiar year-month-day representation. Notice that subtracting one date value from another date value produces an integer value: the number of days between the two specified days. The value is sensitive to Gregorian calendar leap years. Try this: ```plpgsql select pg_typeof('2019-02-14'::date - '2018-02-14'::date)::text as "data type of difference between dates"; ``` This is the result: ```output data type of difference between dates integer ``` Notice that this example takes advantage of the fact that the value of any data type, d, can be ::text typecast to a canonical representation and that a text value that uses the canonical representation format can be ::d typecast to a d valueand that the round trip is non-lossy. Now try this: ```plpgsql select '2019-02-14'::date - '2017-02-14'::date as "not spanning a leap year", '2021-02-14'::date - '2019-02-14'::date as "spanning a leap year"; ``` This is the result: ```output not spanning a leap year | spanning a leap year --+- 730 | 731 ```
Project: TiDB (App Definition and Development / Database)
File: 2019-01-25-skyline-pruning.md

Author(s): Last updated: 2019-01-25 Discussion at: This proposal introduces some heuristics and a general framework for pruning the access paths. With the help of it, the optimizer can avoid some wrong choices on access paths. Currently, the choice of access path strongly depends on the statistics. We may choose the wrong index due to outdated statistics. However, many of the wrong choices can be eliminated by simple heuristics, for example, if the primary key or unique indices can be fully matched, we can choose it without the referring to the statistics. The most important factors to choose the access paths are the number of rows that need to be scanned, whether or not it matches the physical property and does it require a double scan. Among these three factors, only the scan row count depends on statistics. So how can we compare the scan row count without statistics? Let's take a look at an example: ```sql create table t(a int, b int, c int, index idx1(b, a), index idx2(a)); select * from t where a = 1 and b = 1; ``` From the query and schema, we can know that the access condition of `idx1` could strictly cover `idx2`, therefore the number of rows scanned by `idx1` will be no more than `idx2`, so `idx1` will be better than `idx2` in this case. So how can we combine these factors to prune the access paths? Consider two access paths `x` and `y`, if `x` is not worse than `y` at all factors, and there exists one factor that `x` is better than `y`, then we can prune `y` before referring to the statistics, because `x` works better than `y` at all circumstances. This is also called skyline pruning. The skyline pruning is also implemented in other databases, including MySQL and OceanBase. Without it, we may suffer from choosing the wrong access path in some simple cases. It does not affect the compatibility. Since we need to decide whether the access path matches the physical property, we need to do the skyline pruning when finding the best task for the data source. And usually there won't be too many indices, a naive nested-loops algorithm will suffice. The comparison of any two access paths has been explained in the previous `Proposal` section.
Project: YDB (App Definition and Development / Database)
File: topic-create.md

You can use the `topic create` subcommand to create a new topic. General format of the command: ```bash {{ ydb-cli }} [global options...] topic create [options...] <topic-path> ``` `global options`: . `options`: . `topic-path`: Topic path. View the description of the create topic command: ```bash {{ ydb-cli }} topic create --help ``` | Name | Description | | | `--partitions-count` | The number of topic .<br>The default value is `1`. | | `--retention-period-hours` | Data retention time in a topic, set in hours.<br>The default value is `18`. | | `--partition-write-speed-kbps` | The maximum write speed to a , specified in KB/s.<br>The default value is `1024`. | | `--retention-storage-mb` | The maximum storage size, specified in MB. When the limit is reached, the oldest data will be deleted.<br>The default value is `0` (no limit). | | `--supported-codecs` | Supported data compression methods. Set with a comma.<br>The default value is `raw`.<br>Possible values:<ul><li>`RAW`: No compression.</li><li>`ZSTD`: compression.</li><li>`GZIP`: compression.</li><li>`LZOP`: compression.</li></ul> | | `--metering-mode` | The topic pricing method for a serverless database.<br>Possible values:<ul><li>`request-units`: Based on actual usage.</li><li>`reserved-capacity`: Based on dedicated resources.</li></ul> | {% include %} Create a topic with 2 partitions, `RAW` and `GZIP` compression methods, message retention time of 2 hours, and the `my-topic` path: ```bash {{ ydb-cli }} -p quickstart topic create \ --partitions-count 2 \ --supported-codecs raw,gzip \ --retention-period-hours 2 \ my-topic ``` View parameters of the created topic: ```bash {{ ydb-cli }} -p quickstart scheme describe my-topic ``` Result: ```text RetentionPeriod: 2 hours PartitionsCount: 2 SupportedCodecs: RAW, GZIP ```
Project: KICS (Provisioning / Security & Compliance)
File: apache-check.md

Your pull request can't be merged due to missing the Apache license statement. Please add the following statement at the end of the pr description: `I submit this contribution under the Apache-2.0 license.` In case the statement has already been added, make sure it is the last sentence in the description and the only one in its line. Thank you! KICS Team
Project: ArangoDB (App Definition and Development / Database)
File: metaprogrammg3.md

+++ title = "Alternatives" description = "" weight = 60 +++ No doubt many will dislike the two-stage invocation pattern i.e. ```c++ make<file_handle>{"hello"}(); ``` So let us examine the most obvious alternative: a templated free function `make<T>`. Due to the inability to partially specialise templated functions in C++, you need to use tagged overloading e.g. ```c++ template<class... Args> inline outcome::result<filehandle> make(std::inplacetypet<file_handle>, Args&& ... args) { return file_handle::file(std::forward<Args>(args)...); } ... // Now you must always write this: make(std::inplacetype<file_handle>, "hello"); ``` Tagged overloading is fine for smaller projects, but for larger code bases: It takes longer to type `make(std::inplacetype<file_handle>, "hello")`, and is possibly less intuitive to write, than it does `make<file_handle>{"hello"}()`. Compiler error messages are enormously clearer if you encode the permitted overloads for construction into the `make<file_handle>` type rather than letting a variadic free function fail to resolve an appropriate overload. Resolving variadic free function overloads is not constant time for the compiler, whereas resolving the type specialisation for `make<file_handle>` is constant time. In other words, free functions are expensive on build times, whereas fully specialised types are not. It actually turns out to be quite useful when writing generic code to pass around object constructing factory objects all of which have no parameters for their call operator. It becomes, effectively, a lazy construction mechanism.
Project: StarRocks (App Definition and Development / Database)
File: refactoring-request.md

name: Refactoring Request about: Suggest a refactoring for this project labels: 'type/refactoring-request' <!-- (At least include the following, feel free to add if you have more content) --> Is your refactoring request related to a problem? Please describe. <!-- A clear and concise description of what the problem is. Ex. I'm having problems reading the code/add a feature because [...] --> Describe the solution you'd like <!-- A clear and concise description of the refactoring you want to. --> Describe alternatives you've considered <!-- A clear and concise description of any alternative solutions or refactoring method you've considered. --> Additional context <!-- Add any other context or screenshots about the refactoring request here. -->
Project: KICS (Provisioning / Security & Compliance)
File: 69bbc5e3-0818-4150-89cc-1e989b48f23b.md

title: Ingress Controller Exposes Workload hide: toc: true navigation: true <style> .highlight .hll { background-color: #ff171742; } .md-content { max-width: 1100px; margin: 0 auto; } </style> Query id: 69bbc5e3-0818-4150-89cc-1e989b48f23b Query name: Ingress Controller Exposes Workload Platform: Kubernetes Severity: <span style="color:#ff7213">Medium</span> Category: Insecure Configurations URL: Ingress Controllers should not expose workload in order to avoid vulnerabilities and DoS attacks<br> ```yaml title="Positive test num. 1 - yaml file" hl_lines="31" apiVersion: v1 kind: Service metadata: name: app labels: app: app spec: type: ClusterIP ports: port: 3000 targetPort: 3000 selector: app: app apiVersion: extensions/v1beta1 kind: Ingress metadata: name: app-ingress annotations: kubernetes.io/ingress.class: "nginx" labels: app: app spec: rules: host: app.acme.org http: paths: backend: serviceName: app servicePort: 3000 ``` ```yaml title="Negative test num. 1 - yaml file" apiVersion: v1 kind: Service metadata: name: app labels: app: app spec: type: ClusterIP ports: port: 3000 targetPort: 3000 selector: app: app apiVersion: extensions/v1beta1 kind: Ingress metadata: name: app-ingress annotations: kubernetes.io/ingress.class: "nginx" labels: app: app spec: rules: host: app.acme.org http: paths: backend: serviceName: app2 servicePort: 3000 ```
Project: YugabyteDB (App Definition and Development / Database)
File: ddl_grant_role.md

title: GRANT ROLE statement [YCQL] headerTitle: GRANT ROLE linkTitle: GRANT ROLE description: Use the GRANT ROLE statement to grant a role's permissions and SUPERUSER status to another role. menu: v2.18: parent: api-cassandra weight: 1282 type: docs Use the `GRANT ROLE` statement to grant a role's permissions and SUPERUSER status to another role. More than one role can be granted to another role, and the receiving role will possess the union of all the permissions from the roles granted to it (either directly of indirectly through inheritance) plus the SUPERUSER status if any of the roles granted to it has it. For example, if A is granted to B, and B is granted to C, C will be granted all the permissions from A and B, and if either A or B is a SUPERUSER, then C will also be a SUPERUSER. Granted roles form an acyclic graph, in other words, a role cannot be granted to any of the roles granted to it either directly or indirectly. For example, if A is granted to B, and B granted to C, C cannot be granted to neither A, B, nor C. This statement is enabled by setting the YB-TServer flag to `true`. <svg class="rrdiagram" version="1.1" xmlns:xlink="http://www.w3.org/1999/xlink" xmlns="http://www.w3.org/2000/svg" width="305" height="35" viewbox="0 0 305 35"><path class="connector" d="M0 22h5m61 0h10m84 0h10m36 0h10m84 0h5"/><rect class="literal" x="5" y="5" width="61" height="25" rx="7"/><text class="text" x="15" y="22">GRANT</text><a xlink:href="../grammardiagrams#role-name"><rect class="rule" x="76" y="5" width="84" height="25"/><text class="text" x="86" y="22">rolename</text></a><rect class="literal" x="170" y="5" width="36" height="25" rx="7"/><text class="text" x="180" y="22">TO</text><a xlink:href="../grammardiagrams#role-name"><rect class="rule" x="216" y="5" width="84" height="25"/><text class="text" x="226" y="22">rolename</text></a></svg> ```ebnf grantrole ::= GRANT ROLE rolename TO role_name ``` Where `role_name` is a text identifier. Both roles must exist or an error will be raised. Permission `AUTHORIZE` on `ALL ROLES` or on the roles being used in the statement is necessary. Otherwise, an unauthorized error will be returned. If a role is granted to any role granted to it (either directly or indirectly), an error will be raised. ```sql ycqlsh:example> GRANT ROLE eng to robert; ```
Project: KICS (Provisioning / Security & Compliance)
File: 59571246-3f62-4965-a96f-c7d97e269351.md

title: Google Project Auto Create Network Disabled hide: toc: true navigation: true <style> .highlight .hll { background-color: #ff171742; } .md-content { max-width: 1100px; margin: 0 auto; } </style> Query id: 59571246-3f62-4965-a96f-c7d97e269351 Query name: Google Project Auto Create Network Disabled Platform: Terraform Severity: <span style="color:#ff7213">Medium</span> Category: Insecure Configurations URL: Verifies if the Google Project Auto Create Network is Disabled<br> ```tf title="Positive test num. 1 - tf file" hl_lines="8 5" resource "google_project" "positive1" { name = "My Project" project_id = "your-project-id" org_id = "1234567" autocreatenetwork = true } resource "google_project" "positive2" { name = "My Project" project_id = "your-project-id" org_id = "1234567" } ``` ```tf title="Negative test num. 1 - tf file" resource "google_project" "negative1" { name = "My Project" project_id = "your-project-id" org_id = "1234567" autocreatenetwork = false } ```
Project: StarRocks (App Definition and Development / Database)
File: DROP_STATS.md

displayed_sidebar: "English" Deletes CBO statistics, which include basic statistics and histograms. For more information, see . You can delete statistical information you do not need. When you delete statistics, both the data and metadata of the statistics are deleted, as well as the statistics in expired cache. Note that if an automatic collection task is ongoing, previously deleted statistics may be collected again. You can use `SHOW ANALYZE STATUS` to view the history of collection tasks. This statement is supported from v2.4. ```SQL DROP STATS tbl_name ``` ```SQL ANALYZE TABLE tblname DROP HISTOGRAM ON colname [, col_name]; ``` For more information about collecting statistics for CBO, see .
Project: SeaTunnel (App Definition and Development / Streaming & Messaging)
File: field-mapper.md

FieldMapper transform plugin Add input schema and output schema mapping. | name | type | required | default value | |--|--|-|| | field_mapper | Object | yes | | Specify the field mapping relationship between input and output Transform plugin common parameters, please refer to for details. The data read from source is a table like this: | id | name | age | card | |-|-|--|| | 1 | Joy Ding | 20 | 123 | | 2 | May Ding | 20 | 123 | | 3 | Kin Dom | 20 | 123 | | 4 | Joy Dom | 20 | 123 | We want to delete `age` field and update the filed order to `id`, `card`, `name` and rename `name` to `new_name`. We can add `FieldMapper` transform like this ``` transform { FieldMapper { sourcetablename = "fake" resulttablename = "fake1" field_mapper = { id = id card = card name = new_name } } } ``` Then the data in result table `fake1` will like this | id | card | new_name | |-||-| | 1 | 123 | Joy Ding | | 2 | 123 | May Ding | | 3 | 123 | Kin Dom | | 4 | 123 | Joy Dom | Add Copy Transform Connector