mirror of https://github.com/apache/iotdb
93 lines
4.2 KiB
Markdown
93 lines
4.2 KiB
Markdown
|
<!--
|
||
|
|
||
|
Licensed to the Apache Software Foundation (ASF) under one
|
||
|
or more contributor license agreements. See the NOTICE file
|
||
|
distributed with this work for additional information
|
||
|
regarding copyright ownership. The ASF licenses this file
|
||
|
to you under the Apache License, Version 2.0 (the
|
||
|
"License"); you may not use this file except in compliance
|
||
|
with the License. You may obtain a copy of the License at
|
||
|
|
||
|
http://www.apache.org/licenses/LICENSE-2.0
|
||
|
|
||
|
Unless required by applicable law or agreed to in writing,
|
||
|
software distributed under the License is distributed on an
|
||
|
"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
|
||
|
KIND, either express or implied. See the License for the
|
||
|
specific language governing permissions and limitations
|
||
|
under the License.
|
||
|
|
||
|
-->
|
||
|
|
||
|
<!-- Thanks for trying to help us make Apache IoTDB be the best it can be!
|
||
|
Please fill out as much of the following information as is possible (where relevant, and remove it
|
||
|
when irrelevant) to help make the intention and scope of this PR clear in order to ease review. -->
|
||
|
|
||
|
## Description
|
||
|
|
||
|
<!-- Describe the goal of this PR, what problem are you fixing. If there is a corresponding issue,
|
||
|
it's not necessary to repeat the description here,
|
||
|
however, you may choose to keep one summary sentence. -->
|
||
|
|
||
|
<!-- Describe your patch: what did you change in code? How did you fix the problem? -->
|
||
|
|
||
|
<!-- If there are several relatively logically separate changes in this PR, create a mini-section
|
||
|
for each of them. For example: -->
|
||
|
|
||
|
### Content1 ...
|
||
|
### Content2 ...
|
||
|
### Content3 ...
|
||
|
|
||
|
<!--
|
||
|
In each section, please describe design decisions made, including:
|
||
|
- Choice of algorithms
|
||
|
- Behavioral aspects. What configuration values are acceptable? How are corner cases and error
|
||
|
conditions handled, such as when there are insufficient resources?
|
||
|
- Class organization and design (how the logic is split between classes, inheritance, composition,
|
||
|
design patterns)
|
||
|
- Method organization and design (how the logic is split between methods, parameters and return types)
|
||
|
- Naming (class, method, API, configuration, HTTP endpoint, names of emitted metrics)
|
||
|
-->
|
||
|
|
||
|
|
||
|
<!-- It's good to describe an alternative design (or mention an alternative name) for every design
|
||
|
(or naming) decision point and compare the alternatives with the designs that you've implemented
|
||
|
(or the names you've chosen) to highlight the advantages of the chosen designs and names. -->
|
||
|
|
||
|
<!-- If there was a discussion of the design of the feature implemented in this PR elsewhere
|
||
|
(e. g. a "Proposal" issue, any other issue, or a thread in the development mailing list),
|
||
|
link to that discussion from this PR description and explain what have changed in your final design
|
||
|
compared to your original proposal or the consensus version in the end of the discussion.
|
||
|
If something hasn't changed since the original discussion, you can omit a detailed discussion of
|
||
|
those aspects of the design here, perhaps apart from brief mentioning for the sake of readability
|
||
|
of this PR description. -->
|
||
|
|
||
|
<!-- Some of the aspects mentioned above may be omitted for simple and small changes. -->
|
||
|
|
||
|
<hr>
|
||
|
|
||
|
This PR has:
|
||
|
- [ ] been self-reviewed.
|
||
|
- [ ] concurrent read
|
||
|
- [ ] concurrent write
|
||
|
- [ ] concurrent read and write
|
||
|
- [ ] added documentation for new or modified features or behaviors.
|
||
|
- [ ] added Javadocs for most classes and all non-trivial methods.
|
||
|
- [ ] added or updated version, __license__, or notice information
|
||
|
- [ ] added comments explaining the "why" and the intent of the code wherever would not be obvious
|
||
|
for an unfamiliar reader.
|
||
|
- [ ] added unit tests or modified existing tests to cover new code paths, ensuring the threshold
|
||
|
for code coverage.
|
||
|
- [ ] added integration tests.
|
||
|
- [ ] been tested in a test IoTDB cluster.
|
||
|
|
||
|
<!-- Check the items by putting "x" in the brackets for the done things. Not all of these items
|
||
|
apply to every PR. Remove the items which are not done or not relevant to the PR. None of the items
|
||
|
from the checklist above are strictly necessary, but it would be very helpful if you at least
|
||
|
self-review the PR. -->
|
||
|
|
||
|
<hr>
|
||
|
|
||
|
##### Key changed/added classes (or packages if there are too many classes) in this PR
|
||
|
|
||
|
<!-- Template copied and modified from Apache Druid-->
|