11.4 Schema options

This section describes the various Schema options that are available.

Free-form comments are allowed (encouraged) in your schema files

 Comments may be placed anywhere on a line after a pound sign (``#''). You can begin lines with a ``#'' to provide block comments or place the ``#'' at the end of each line to document lines separately. Qddb ignores any text following the ``#'' character. See figure 11.5 for a sample schema with comments.

11.4.2 verbosename

 The verbosename keyword provides an option for you to specify a more verbose name for your attribute. In particular, the verbosename value is used by nxqddb to determine the label that appears to the left of the entry on the nxqddb window. For example, consider the schema shown in figure 11.3, and its accompanying nxqddb window in figure 11.4. In this schema, we created verbosenames for each attribute. Remember, attribute names cannot have spaces. Hence, we use the verbosename option to create labels that have spaces. We also added colons to the end of the verbosename to help serve as a delimiter to the entry field.

name verbosename "Full Name: "
number verbosename "Phone Number: "
ssn verbosename "Social Security Number: "

  
Figure 11.3: Schema with verbosenames

  
Figure 11.4: nxqddb window using a schema with verbosenames

11.4.3 type

 The default type for an attribute is string. You can change an attribute's type by keying the phrase ``type <TYPEVALUE>'' next to an attribute. Figure 11.5 provides example schemas that illustrate how to define the various types.

#
# Schema to illustrate "types''
#
Name                             # this field defaults to type string
Birthday type date               # date field
Cash type real format "%6.2f"  # currency field, 6 digits with 2 to right of decimal
Number type integer              # define an integer field (accepts positive or negative integers)

  
Figure 11.5: Schema illustrating how to define the various types of attributes

So, what does it mean to declare something as string versus, say an integer? If you declare an attribute as an integer, nxqddb will only allow you to type numeric characters in the entry field. Meaning, nxqddb restricts your input to a valid integer. Similar validation is performed on real, and date attributes.

11.4.4 format

  The format keyword tells nxqddb how to print/display attributes that are defined as (1) type date, (2) type integer and (3) type real. If you don't have one of the above three types of attributes, then nxqddb will just ignore the format qualifier. The format keyword has no impact on how you enter the data; remember, the validation is handled based on the type.

integer format

For integers, you may specify any of the standard ``non-``C'' programmers, this format allows you to specify things like padding, zero-fill, etc. The default format is ``To learn more about how to format integers, reference your online man page by entering the following at your command prompt: man 3 printf Common integer formats are illustrated in figure 11.1

  
Table 11.1: Examples of formatting integer types

real format

Similarly to integers, you can specify the format for real numbers. Users commonly specify the precision of the real number using the ``

  
Table 11.2: Examples of formatting real types

The default format for real types is ``

date format

For formatting date attributes, you may specify almost any combination of the ones illustrated in figure 11.3. For further details on the date format, see the man pages for strftime(3), asctime(3), and mktime(3). The default format for dates is either ``installation of Qddb was configured

  
Table 11.3: Date format options

You may enter dates in almost any format, except that ``nn/nn/nn'' is interpreted as ``%m/%d/%y''. You can override this interpretation when you install Qddb so that such input will be interpreted ``%d/%m/%y''. Some combinations of date format, such as ``%d;%b;%y'', are not currently recognized by Qddb. If you provide a date format that Qddb cannot interpret, you will see an error when entering dates. Most common formats are supported.

You may also enter dates relative to some date(see table 11.4).

  
Table 11.4: Keywords available for date attributes

You may also use the day-of-week keywords Monday, Tuesday, Wednesday, Thursday, Friday, Saturday, and Sunday. Month names are also fine. For example, the following are all valid input to a date attribute:

The input ``next tuesday'' does not mean this coming (or current) Tuesday, but the one after. The keyword ``tuesday'' means the coming (or current) Tuesday.

11.4.5 alias

 Aliases provide a way to provide a simple (often much shorter) name to an attribute. The use of aliases are especially helpful if you are programming with Qtcl and you have many levels of nested structured attributes. Also, using aliases, you can save some typing whenever you create your custom Email, letters and postcards through the nxqddb report generator. The alias syntax is simple, for example to alias a ``SocialSecurityNumber'' field, you might enter SocialSecurityNumber alias ssn.

11.4.6 defaultvalues

 You can tell nxqddb to prepopulate an entry with a default value when you are in ``Add Mode''. For example, consider a ``City'' attribute. If most of your entries live in say ``Cincinnati'', you could specify a default value of ``Cincinnati'' and this value would appear in the nxqddb window whenever you go to ``Add Mode''.

Many users find it convenient to prepopulate ZipCode attributes with a partial default value. For example, suppose you happen to have say 95of the five zip codes 41016, 41042, 41017, 41011 and 41015. In this case, you would create the ZipCode schema like so: ZipCode defaultvalues ``410''

11.4.7 exclude

 The exclude option tells Qddb to exclude indexing on the attribute. If you specify the exclude option on a field, you will not be able to perform searching on the field. Typically, you want to use the exclude option only on fields that you know will never be used as search criteria fields. For example, fields that you may want to exclude from searching might be: sales tax, subtotals, or any other field that would yield meaningless search results.

11.4.8 separators

 Separators tell nxqddb how your data values are to be parsed into words during a word search. If you don't specify the key word ``separators'', then Qddb abides by the following rules when parsing words:

1. Qddb uses all non-alphanumeric characters as delimiters.
2. If the attribute has ``type real'', +-. are not considered delimiters.
3. If the attribute has ``type integer'' or ``type date'', +- are not considered delimiters
4. A newline is always a delimiter

The default separators are shown below:

string

The string default separators are:

" 0r!@#$%^&*()_+-={[];':

real

The default separators for real are the same as string except for the minus(-) and plus(+) characters.

integer

Same as string except for the minus(-) and plus (+).

date

Same default separators as integer type attributes.

Example of specifying a separator

Suppose you have data that contains the delimiters: ``:'' and ``/''. For example, say you have a string like ``foo:bar/whatever this is''. To handle this scenario, you would set the separators to ``:/'' as shown in figure 11.6

#
# Schema containing separators
#
MyField separators ":/"

  
Figure 11.6: Schema to illustrate the use of separators