• Home
  • History
  • Annotate
  • Line#
  • Navigate
  • Raw
  • Download
  • only in /asuswrt-rt-n18u-9.0.0.4.380.2695/release/src/router/db-4.8.30/docs/api_reference/CXX/
1<?xml version="1.0" encoding="UTF-8" standalone="no"?>
2<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
3<html xmlns="http://www.w3.org/1999/xhtml">
4  <head>
5    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />
6    <title>db_sql</title>
7    <link rel="stylesheet" href="apiReference.css" type="text/css" />
8    <meta name="generator" content="DocBook XSL Stylesheets V1.73.2" />
9    <link rel="start" href="index.html" title="Berkeley DB C++ API Reference" />
10    <link rel="up" href="utilities.html" title="Appendix 1.  Berkeley DB Command Line Utilities" />
11    <link rel="prev" href="db_recover.html" title="db_recover" />
12    <link rel="next" href="db_stat.html" title="db_stat" />
13  </head>
14  <body>
15    <div class="navheader">
16      <table width="100%" summary="Navigation header">
17        <tr>
18          <th colspan="3" align="center">db_sql</th>
19        </tr>
20        <tr>
21          <td width="20%" align="left"><a accesskey="p" href="db_recover.html">Prev</a> </td>
22          <th width="60%" align="center">Appendix 1. 
23                Berkeley DB Command Line Utilities
24        </th>
25          <td width="20%" align="right"> <a accesskey="n" href="db_stat.html">Next</a></td>
26        </tr>
27      </table>
28      <hr />
29    </div>
30    <div class="sect1" lang="en" xml:lang="en">
31      <div class="titlepage">
32        <div>
33          <div>
34            <h2 class="title" style="clear: both"><a id="db_sql"></a>db_sql</h2>
35          </div>
36        </div>
37      </div>
38      <pre class="programlisting">db_sql [-i &lt;ddl input file&gt;] [-o &lt;output C code file&gt;] 
39    [-h &lt;output header file&gt;] [-t &lt;test output file&gt;]  </pre>
40      <p>
41   <span class="command"><strong>Db_sql</strong></span> is a utility program that translates a
42   schema description written in a SQL Data Definition Language dialect
43   into C code that implements the schema using Berkeley DB.  It is
44   intended to provide a quick and easy means of getting started with
45   Berkeley DB for users who are already conversant with SQL.  It also
46   introduces a convenient way to express a Berkeley DB schema in a
47   format that is both external to the program that uses it and
48   compatible with relational databases.
49 </p>
50      <p>
51   The <span class="command"><strong>db_sql</strong></span> command reads DDL from an input stream,
52   and writes C code to an output stream.  With no command line options,
53   it will read from stdin and write to stdout.  A more common usage mode
54   would be to supply the DDL in a named input file (-i option).  With
55   only the -i option, <span class="command"><strong>db_sql</strong></span> will produce two files:
56   a C-language source code (.c) file and a C-language header (.h) file,
57   with names that are derived from the name of the input file.  You can
58   also control the names of these output files with the -o and -h
59   options.  Finally, the -t option will produce a simple application
60   that invokes the generated function API.  This is a C-language source
61   file that includes a main function, and serves the dual purposes of
62   providing a simple test for the generated C code, and of being an
63   example of how to use the generated API.
64 </p>
65      <p>
66   The options are as follows:
67 </p>
68      <div class="itemizedlist">
69        <ul type="disc">
70          <li>
71            <p>
72       <span class="bold"><strong>-i</strong></span>&lt;ddl input file&gt;
73     </p>
74            <p>
75    Names the input file containing SQL DDL.
76     </p>
77          </li>
78          <li>
79            <p>
80       <span class="bold"><strong>-o</strong></span> &lt;output C code file&gt;
81     </p>
82            <p>
83    Names the output C-language source code file.
84     </p>
85          </li>
86          <li>
87            <p>
88       <span class="bold"><strong>-h</strong></span> &lt;output header file&gt;
89     </p>
90            <p>
91    Names the output C-language header file.
92     </p>
93          </li>
94          <li>
95            <p>
96       <span class="bold"><strong>-t</strong></span> &lt;test output file&gt;
97     </p>
98            <p>
99    Names the output C-langage test file.
100     </p>
101          </li>
102        </ul>
103      </div>
104      <p>
105   The <span class="command"><strong>db_sql</strong></span> utility exits 0 on success, and &gt;0 if an error occurs.
106 </p>
107      <div class="sect2" lang="en" xml:lang="en">
108        <div class="titlepage">
109          <div>
110            <div>
111              <h3 class="title"><a id="id1720398"></a>Input Syntax</h3>
112            </div>
113          </div>
114        </div>
115        <p>
116     The input file can contain the following SQL DDL statements.
117   </p>
118        <div class="itemizedlist">
119          <ul type="disc">
120            <li>
121              <p>
122            <span class="bold"><strong>CREATE DATABASE</strong></span> 
123        </p>
124              <p>
125            The DDL must contain a CREATE DATABASE statement.  The syntax is simply
126            </p>
127              <pre class="programlisting">CREATE DATABASE name;</pre>
128              <p>.  The
129            name given here is used as the name of the Berkeley DB
130            environment in which the Berkeley DB databases are created.
131        </p>
132            </li>
133            <li>
134              <p>
135            <span class="bold"><strong>CREATE TABLE</strong></span>
136        </p>
137              <p>
138            Each CREATE TABLE statement produces functions to create and
139            delete a primary Berkeley DB database.  Also produced are
140            functions to perform record insertion, retrieval and deletion
141            on this database.
142        </p>
143              <p>
144            CREATE TABLE establishes the field set of records that can
145            be stored in the Berkeley DB database.  Every CREATE TABLE
146            statement must identify a primary key to be used as the
147            lookup key in the Berkeley DB database.
148        </p>
149              <p>
150            Here is an example to illustrate the syntax of CREATE TABLE that
151            is accepted by <span class="command"><strong>db_sql</strong></span>:
152        </p>
153              <p>
154      </p>
155              <pre class="programlisting">CREATE TABLE person (person_id INTEGER PRIMARY KEY,
156                        name VARCHAR(64),
157                        age INTEGER);</pre>
158              <p>
159    </p>
160              <p>
161      This results in the creation of functions to manage a database in
162      which every record is an instance of the following C language
163      data structure:
164    </p>
165              <p>
166      </p>
167              <pre class="programlisting">typedef struct _person_data {
168    int person_id;
169    char name[PERSON_DATA_NAME_LENGTH];
170    int age;
171} person_data; </pre>
172              <p>
173    </p>
174            </li>
175            <li>
176              <p>
177      <span class="bold"><strong>CREATE INDEX</strong></span> You can create
178      secondary Berkeley DB databases to be used as indexes into a
179      primary database.  For example, to make an index on the "name"
180      field of the "person" table mentioned above, the SQL DDL would
181      be:
182    </p>
183              <p>
184      </p>
185              <pre class="programlisting">CREATE INDEX name_index ON person(name);</pre>
186              <p>
187    </p>
188              <p>
189      This causes <span class="command"><strong>db_sql</strong></span> to emit functions to
190      manage creation and deletion of a secondary database called
191      "name_index," which is associated with the "person" database
192      and is set up to perform lookups on the "name" field.
193    </p>
194            </li>
195          </ul>
196        </div>
197      </div>
198      <div class="sect2" lang="en" xml:lang="en">
199        <div class="titlepage">
200          <div>
201            <div>
202              <h3 class="title"><a id="id1720745"></a>Hint Comments</h3>
203            </div>
204          </div>
205        </div>
206        <p>
207     The SQL DDL input may contain comments.  Two types of comments are
208     recognized.  C-style comments begin with "/*" and end with "*/".
209     These comments may extend over multiple lines.
210   </p>
211        <p>
212     Single line comments begin with "--" and run to the end of the line.
213   </p>
214        <p>
215     If the first character of a comment is "+" then the comment is
216     interpreted as a "hint comment."  Hint comments can be used to
217     configure Berkeley DB features that cannot be represented in SQL DDL.
218   </p>
219        <p>
220     Hint comments are comma-separated lists of property assignments of the
221     form "property=value."  Hint comments apply to the SQL DDL statement
222     that immediately precedes their appearance in the input.  For example:
223   </p>
224        <p>
225     </p>
226        <pre class="programlisting">CREATE DATABASE peopledb; /*+ CACHESIZE = 16m */</pre>
227        <p>
228   </p>
229        <p>
230     This causes the generated environment creation function to set the
231     cache size to sixteen megabytes.
232   </p>
233        <p>
234     In addition to the CACHESIZE example above, there is only one other
235     hint comment that is currently recognized: After a CREATE TABLE
236     statement, you may set the database type by assigning the DBTYPE
237     property in a hint comment.  Possible values for DBTYPE are BTREE and
238     HASH.
239   </p>
240      </div>
241      <div class="sect2" lang="en" xml:lang="en">
242        <div class="titlepage">
243          <div>
244            <div>
245              <h3 class="title"><a id="id1720591"></a>Type Mapping</h3>
246            </div>
247          </div>
248        </div>
249        <p>
250     <span class="command"><strong>db_sql</strong></span> must map the schema expressed as SQL
251     types into C language types.  It implements the following mappings:
252   </p>
253        <p>
254     </p>
255        <pre class="programlisting">BIN     char[]
256VARBIN      char[]
257CHAR        char[]
258VARCHAR     char[]
259VARCHAR2    char[]
260BIT         char
261TINYINT     char
262SMALLINT    short
263INTEGER     int
264INT         int
265BIGINT      long
266REAL        float
267DOUBLE      double
268FLOAT       double
269DECIMAL     double
270NUMERIC     double
271NUMBER(p,s) int, long, float, or double </pre>
272        <p>
273   </p>
274        <p>
275     While BIN/VARBIN and CHAR/VARCHAR are both represented as char arrays,
276     the latter are treated as null-terminated C strings, while the former
277     are treated as binary data.
278   </p>
279        <p>
280     The Oracle type NUMBER is mapped to different C types, depending
281     on its precision and scale values.  If scale is 0, then it is
282     mapped to an integer type (long if precision is greater than 9).
283     Otherwise it is mapped to a floating point type (float if
284     precision is less than 7, otherwise double).
285   </p>
286      </div>
287      <div class="sect2" lang="en" xml:lang="en">
288        <div class="titlepage">
289          <div>
290            <div>
291              <h3 class="title"><a id="id1720414"></a>Output</h3>
292            </div>
293          </div>
294        </div>
295        <p>
296     Depending on the options given on the command
297     line, <span class="command"><strong>db_sql</strong></span> can produce three separate files: a .c
298     file containing function definitions that implement the generated API;
299     a .h file containing constants, data structures and prototypes of the
300     generated functions; and a second .c file that contains a sample
301     program that invokes the generated API.  The latter program is usually
302     referred to as a smoke test.
303   </p>
304        <p>
305     Given the following sample input in a file named "people.sql":
306   </p>
307        <p>
308     </p>
309        <pre class="programlisting">CREATE DATABASE peopledb;
310CREATE TABLE person (person_id INTEGER PRIMARY KEY,
311                  name VARCHAR(64),
312                  age INTEGER);
313CREATE INDEX name_index ON person(name);</pre>
314        <p>
315   </p>
316        <p>
317     The command
318   </p>
319        <p>
320     </p>
321        <pre class="programlisting">db_sql -i people.sql -t test_people.c</pre>
322        <p>
323   </p>
324        <p>
325     Will produce files named people.h, people.c, and test_people.c.
326   </p>
327        <p>
328     The file people.h will contain the information needed to use the
329     generated API.  Among other things, an examination of the generated .h
330     file will reveal:
331   </p>
332        <p>
333     </p>
334        <pre class="programlisting">#define PERSON_DATA_NAME_LENGTH 63</pre>
335        <p>
336   </p>
337        <p>
338     This is just a constant for the length of the string mapped from
339     the VARCHAR field.
340   </p>
341        <p>
342     </p>
343        <pre class="programlisting">typedef struct _person_data {
344   int   person_id;
345   char  name[PERSON_DATA_NAME_LENGTH];
346   int   age;
347} person_data; </pre>
348        <p>
349   </p>
350        <p>
351     This is the data structure that represents the record type that is
352     stored in the person database.  There's that constant being used.
353   </p>
354        <p>
355     </p>
356        <pre class="programlisting">int create_peopledb_env(DB_ENV **envpp);
357int create_person_database(DB_ENV *envp, DB **dbpp);
358int create_name_index_secondary(DB_ENV *envp, DB *primary_dbp,
359                            DB **secondary_dbpp); </pre>
360        <p>
361   </p>
362        <p>
363     These functions must be invoked to initialize the Berkeley DB
364     environment.  However, see the next bit:
365   </p>
366        <p>
367     </p>
368        <pre class="programlisting">extern DB_ENV * peopledb_envp;
369extern DB *person_dbp;
370extern DB *name_index_dbp;
371
372int initialize_peopledb_environment(); </pre>
373        <p>
374   </p>
375        <p>
376     For convenience, <span class="command"><strong>db_sql</strong></span> provides global
377     variables for the environment and database, and a single
378     initialization function that sets up the environment for you.
379     You may choose to use the globals and the single initialization
380     function, or you may declare your own DB_ENV and DB pointers,
381     and invoke the individual create_* functions yourself.
382   </p>
383        <p>
384     The word "create" in these function names might be confusing.  It means
385     "create the environment/database if it doesn't already exist;
386     otherwise open it."
387   </p>
388        <p>
389     All of the functions in the generated API return Berkeley DB error
390     codes.  If the return value is non-zero, there was an error of some
391     kind, and an explanatory message should have been printed on stderr.
392   </p>
393        <p>
394     </p>
395        <pre class="programlisting">int person_insert_struct(DB *dbp, person_data *personp);
396int person_insert_fields(DB * dbp,
397        int person_id,
398        char *name,
399        int age); </pre>
400        <p>
401   </p>
402        <p>
403     These are the functions that you'd use to store a record in the
404     database.  The first form takes a pointer to the data structure that
405     represents this record.  The second form takes each field as a
406     separate argument.
407   </p>
408        <p>
409     If two records with the same primary key value are stored, the first
410     one is lost.
411   </p>
412        <p>
413     </p>
414        <pre class="programlisting">int get_person_data(DB *dbp, int person_key, person_data *data);</pre>
415        <p>
416   </p>
417        <p>
418     This function retrieves a record from the database.  It seeks the
419     record with the supplied key, and populates the supplied structure
420     with the contents of the record.  If no matching record is found, the
421     function returns DB_NOTFOUND.
422   </p>
423        <p>
424     </p>
425        <pre class="programlisting">int delete_person_key(DB *dbp, int person_key);</pre>
426        <p>
427   </p>
428        <p>
429     This function removes the record matching the given key.
430   </p>
431        <p>
432     </p>
433        <pre class="programlisting">typedef void (*person_iteration_callback)(void *user_data, 
434                                         person_data *personp);
435
436int person_full_iteration(DB *dbp,
437    person_iteration_callback user_func,
438    void *user_data); </pre>
439        <p>
440   </p>
441        <p>
442      This function performs a complete iteration over every record in
443      the person table.  The user must provide a callback function
444      which is invoked once for every record found.  The user's
445      callback function must match the prototype provided in the
446      typedef "person_iteration_callback."  In the callback, the
447      "user_data" argument is passed unchanged from the "user_data"
448      argument given to person_full_iteration.  This is provided
449      so that the caller of person_full_iteration can communicate
450      some context information to the callback function.  The
451      "personp" argument to the callback is a pointer to the record
452      that was retrieved from the database.  Personp points to data
453      that is valid only for the duration of the callback invocation.
454   </p>
455        <p>
456     </p>
457        <pre class="programlisting">int name_index_query_iteration(DB *secondary_dbp,
458    char *name_index_key,
459    person_iteration_callback user_func,
460    void *user_data); </pre>
461        <p>
462   </p>
463        <p>
464     This function performs lookups through the secondary index
465     database.  Because duplicate keys are allowed in secondary
466     indexes, this query might return multiple instances.  This
467     function takes as an argument a pointer to a user-written
468     callback function, which must match the function prototype
469     typedef mentioned above (person_iteration_callback).  The
470     callback is invoked once for each record that matches the
471     secondary key.
472   </p>
473      </div>
474      <div class="sect2" lang="en" xml:lang="en">
475        <div class="titlepage">
476          <div>
477            <div>
478              <h3 class="title"><a id="id1720958"></a>Test output</h3>
479            </div>
480          </div>
481        </div>
482        <p>
483     The test output file is useful as an example of how to invoke the
484     generated API.  It will contain calls to the functions mentioned above,
485     to store a single record and retrieve it by primary key and through
486     the secondary index.
487   </p>
488        <p>
489     To compile the test, you would issue a command such as
490   </p>
491        <p>
492     </p>
493        <pre class="programlisting"> cc -I$BDB_INSTALL/include -L$BDB_INSTALL/lib -o test_people people.c \
494     test_people.c -ldb-4.8</pre>
495        <p>
496   </p>
497        <p>
498     This will produce the executable file test_people, which can be
499     run to exercise the generated API.  The program generated from
500     people.sql will create a database environment in a directory
501     named "peopledb."  This directory must be created before the
502     program is run.
503   </p>
504      </div>
505    </div>
506    <div class="navfooter">
507      <hr />
508      <table width="100%" summary="Navigation footer">
509        <tr>
510          <td width="40%" align="left"><a accesskey="p" href="db_recover.html">Prev</a> </td>
511          <td width="20%" align="center">
512            <a accesskey="u" href="utilities.html">Up</a>
513          </td>
514          <td width="40%" align="right"> <a accesskey="n" href="db_stat.html">Next</a></td>
515        </tr>
516        <tr>
517          <td width="40%" align="left" valign="top">db_recover </td>
518          <td width="20%" align="center">
519            <a accesskey="h" href="index.html">Home</a>
520          </td>
521          <td width="40%" align="right" valign="top"> db_stat</td>
522        </tr>
523      </table>
524    </div>
525  </body>
526</html>
527