!1229 Spelling corrections in new-index.md and odbc.md
Merge pull request !1229 from i-robot/pull146
This commit is contained in:
commit
82cd2a33f7
|
|
@ -10,17 +10,13 @@ The `getID()` method in the `Index` interface returns the ID of this index type
|
|||
|
||||
### Level
|
||||
|
||||
A heuristic index stores additional and usually partial information of a dataset in a more compact way to speed up lookups in various ways. Therefore, each index must
|
||||
have a domain on which it is applied. For instance, if an index marks the max value of a data set, we must know how big the data set is when we define the "max" value (i.e.
|
||||
it can be the max of a group of rows, a data partition, or even a whole table). When a new index type is created, it must implement a method `Set<Level> getSupportedIndexLevels();`
|
||||
which returns the data set level it can support. The levels are defined as an enum in `Index` interface.
|
||||
A heuristic index stores additional and usually partial information of a dataset in a more compact way to speed up lookups in various ways. Therefore, each index must have a domain on which it is applied. For instance, if an index marks the max value of a data set, we must know how big the data set is when we define the "max" value (i.e. it can be the max of a group of rows, a data partition, or even a whole table). When a new index type is created, it must implement a method `Set<Level> getSupportedIndexLevels();` which returns the data set level it can support. The levels are defined as an enum in `Index` interface.
|
||||
|
||||
## Interface overlook
|
||||
|
||||
### Indexing methods
|
||||
|
||||
Apart from the methods metioned above, this section gives a quick guide on the most important methods needed to create a new index type. For the complete
|
||||
document on `Index` interface, please refer to the Java Doc of the source code.
|
||||
Apart from the methods mentioned above, this section gives a quick guide on the most important methods needed to create a new index type. For the complete document on `Index` interface, please refer to the Java Doc of the source code.
|
||||
|
||||
There are two main functionalities in the `Index` interface:
|
||||
|
||||
|
|
@ -46,7 +42,7 @@ boolean addValues(Map<String, List<Object>> values) throws IOException;
|
|||
Index deserialize(InputStream in) throws IOException;
|
||||
|
||||
void serialize(OutputStream out) throws IOException;
|
||||
```
|
||||
```
|
||||
|
||||
The usage of them are pretty straightforward. A good example to help understand their usage is the source code of `MinMaxIndex`, where adding values is just to
|
||||
update the `max` and `min` variables according to the input number, and `serialize()/deserialize()`
|
||||
|
|
@ -61,7 +61,7 @@ Before an application uses the openLooKeng ODBC driver, the data source DSN must
|
|||
|
||||
### Opening the ODBC Data Source Administrator (64-bit)
|
||||
|
||||
1. Click **Start**, and choose **Control Panel**.
|
||||
1. Click **Start** and choose **Control Panel**.
|
||||
|
||||
2. In **Control Panel**, click **System and Security**, and then click **Administrative Tools**.
|
||||
|
||||
|
|
@ -171,6 +171,6 @@ You can obtain the details about data types by calling **SQLGetTypInfo** in **Ca
|
|||
|
||||
The openLooKeng ODBC driver supports **both ANSI and Unicode** applications. The default connection character set is the system default character set for ANSI applications and utf8 for Unicode applications. If the character set used by the application is different from the above-mentioned character set, it may cause garbled characters. For this, the user should specify the connection character set to adapt to the character set required by the application. The corresponding configuration of the connection character set is described as follows.
|
||||
|
||||
When calling the ODBC API to retrieve data, if bound to the SQL_C_WCHAR C data type buffer, the driver will return the Unicode encoded result for both ANSI and Unicode applications. When bound to the SQL_C_CHAR C data type buffer, by deafult, the driver will return to the ANSI application the result encoded in system default character set, and for Unicode application the driver will return the result encoded in utf8. If the encoding character set used by the application does not match the default, the result may be garbled. To this end, the user should configure the connection character set to specify the encoding of the result. For example, if the application has garbled Chinese characters, you can try to configure the connection character set to GBK or GB2312.
|
||||
When calling the ODBC API to retrieve data, if bound to the SQL_C_WCHAR C data type buffer, the driver will return the Unicode encoded result for both ANSI and Unicode applications. When bound to the SQL_C_CHAR C data type buffer, by default, the driver will return to the ANSI application the result encoded in system default character set, and for Unicode application the driver will return the result encoded in utf8. If the encoding character set used by the application does not match the default, the result may be garbled. To this end, the user should configure the connection character set to specify the encoding of the result. For example, if the application has garbled Chinese characters, you can try to configure the connection character set to GBK or GB2312.
|
||||
|
||||
While configuring data source all connection character sets supported by the openLooKeng ODBC driver can be set in the **Character Set** drop-down box on the page 3 of the User interface. User can select the connection character from the drop-down box after the **Test DSN** is success.
|
||||
Loading…
Reference in New Issue