py4sci

Table Of Contents

Previous topic

HTSQL Reference Manual

Next topic

1.3.5.1. Date And Time Properties

1. Basic Concepts

This chapter describes main structural elements of HTSQL language.

1.1. Abstract

1.1.1. Understanding HTSQL

HTSQL query may be considered in two perspectives. Since HTSQL translates query into SQL, each HTSQL syntax construct has SQL equivalent. That’s why SQL and database structure perspective can be used for understanding HTSQL syntax issues. HTSQL has full analogs of different SQL statements, SELECT and WHERE clauses, grouping and aggregation, etc.

On the other hand, HTSQL has object-oriented traits and some issues are easier to understand in object-oriented perspective. For example, specifier or context terms, identifier resolution are much like objects and their properties.

These two perspective are used both in current documentation.

1.1.2. How to read syntax diagrams

Double quoted symbols come as is into resulting construction.

Non-quoted terms come for basic language elemets or other subconstructions, defined elsewhere (hyperlinks to subconstructions are indicated right below the diagram).

Non-quoted symbols are predefined:
  • [ ] constructions within square brackets are optional
  • [ ]... optional constructions followed by dots may occur more than once
  • { | } curly brackets mean one of several variants. Variant constructions are separated with vertical bar symbol “|”.

Some diagrams are split into several lines for better readability.

1.2. HTSQL catalog

HTSQL doesn’t address database objects directly. It handles its own entities instead, which are mapped on database objects. Text-based file, that describes database structure and htsql entities mapping, is called catalog.

Structure of HTSQL catalog is out of scope of the current reference, but htsql entities and their mapping are considered here. HTSQL entities are:

  • authority
  • perspective
  • aspect
  • field

Entities are linked with “contains” relationship in a hierarchical manner, where authority is top level and field is bottom level.

Authority identifies actor, on whose behalf htsql queries are executed. Authority is mapped on database user.

Perspective identifies set of privileges, applyed to an authority. Each authority has list of allowed perspectives and default one, which is applied if no perspective is explicitly specified. For some database management systems perspective is mapped on database role. Privileges in HTSQL are defined on aspects and grant rights to select, insert, update or delete.

Aspect is htsql entity for database table. Aspect full name is composite and consists of namespace and short name. Namespace for aspect stands for database shema.

Field of an aspect is htsql entity for database column of a table.

Catalog also describes primary keys and foreign key references to discover aspect links and perform valid joins.

HTSQL entities may be mapped on database objects not directly, hence considering HTSQL query it’s more correct to talk in terms of aspects and fields rather than tables and columns. However once difference between these terms is realized, for more plainness and clarity further in this reference term table in most cases stands both for database object and HTSQL aspect. The same way term column stands both for database object and HTSQL field.

1.3. Data Types (Domains)

1.3.1. Summary of HTSQL domains

Primitive types:

Domain Subtype Description
boolean   boolean data, taking one of true and false
string   character data
number   generic number type
decimal synonym for number
integer integer
float floating point number
binary   binary data
bitstring   bit string data
date   stores year, month and day
time without timezone stores hours, minutes, seconds and fractional didgits of second
with timezone
stores hours, minutes, seconds, fractional didgits of second and time zone
information including hours and minutes for offset against UTC
datetime without timezone stores year, month, day, hours, minutes, seconds and fractional didgits of second
with timezone
stores year, month, day, hours, minutes, seconds and fractional didgits of second
and time zone information including hours and minutes for offset against UTC
timedelta   stores days, hours, minutes, seconds and fractional didgits of second represents time interval for date and time arithmetic
unknown   represents any other SQL data type, which HTSQL does not support directly

Compound types:

Domain Description
array
Stores numerated list of elements; all of them have the same type.
Elements of array can be accessed by index.
tuple
Stores set of elements of different types. Represents row of the table or row of
selection result. Elements of tuple can be accessed by name.
composite represents SQL composite data types

HTSQL types determine the way data are manipulated and represented, but not the way data are stored. Exact implementation of the data type may differ depending on underlying RDBMS system.

1.3.2. Boolean

Boolean operators list see in section Boolean Operators

Boolean function list see in section Boolean Functions

Boolean conversion details see in section Boolean conversion

1.3.3. String

String operators list see in section String Operators

String function list see in section String Functions

String conversion details see in section String conversion

1.3.4. Numeric

Numeric operators list see in section Numeric Operators

Numeric function list see in section Numeric Functions

Numeric conversion details see in section Numeric conversion

1.3.5. Date and Time

4 domains belong to this group: date, time, datetime, and timedelta.

Date and Time operators list see in section Date And Time Operators

Date and Time function list see in section Date And Time Functions

Date and Time conversion and constructor details see in section Date and Time conversion

Date and Time domains provide list of properties to access stored fields separately. List of properties is common, but they are applicable not to all 4 date-time domains, but to some of them, depending on wether particular domain stores such field or not.

Refer to the section below for detailed information:

1.3.6. Array

Array operators list see in section Array Operators

Array function list see in section Array Functions

Array constructor details see in section Array constructor

1.4. Language elements

1.4.1. Constants

Constants in HTSQL are:
  • literals
  • sequences
  • maps

Literals are constants of primitive types, while sequences and maps are constants of compound types.

1.4.1.1. Literals

String and numeric literals are supported by HTSQL.

More strictly, literals belong to special domain untyped until their actual type is determined from context. For example, within conditional expressions or boolean comparison ‘true’ and ‘false’ literals are implicitly cast to boolean. But in string comparison they are treated as string literals.

1.4.1.1.1. String literals

String literals are single-quoted (‘) character sequences. If signle quote character occurs within a string value, it must be doubled. For example:

'O''Reilly'
--->
  O'Reilly
1.4.1.1.2. Numeric literals

Numeric literals need not be quoted and are just sequences of didgits. All numeric literals are decimal and may contain decimal didgits only (0-9).

1.4.1.2. Sequences

Sequence is a constant of array type and represents ordered set of elemets. Sequence definition:

"[" constant [ "," constant ]... "]"

Sequence elements may be constants of compound type themselves.

1.4.1.3. Maps

Map is a constant of tuple type and represents set of named elemets. Map definition:

"{" name ":" constant [ "," name ":" constant ]... "}"

Where name is a string literal. Map values may be constants of compound type themselves.

1.4.2. Nulls

If a column in a row has no value, then the column is said to be null, or to contain null. All operators return null when given a null operand. Exceptions are special null-safe equality operators and null-checking function is_null .

In fact, HTSQL supports two set of equality operators:

Difference between them and is_null() function is shown in the table:

x y x = y x != y x == y x !== y is_null(x) is_null(y)
10 10 true false true false false false
null 10 null null false true true false
10 null null null false true false true
null null null null true false true true

As shown in the table, simple equality evaluates to null if one of the operands is null, while null-safe equality treats null as another regular value.

Function is_null(x) is equivalent to x == null()

1.4.3. Identifiers

Identifiers in HTSQL are:
  • catalog identifiers: - perspectives - namespaces - aspects - fields
  • functions
  • operators
  • commands
  • aliases
  • variables

Identifiers can be double-quoted (“), or unquoted. If identifier contains double-quotes itself, the symbol is escaped by one more double-quote. For example, Hotel “California” quoted is “Hotel “”California”“”

Catalog identifiers when quoted are resolved using exact matching, while unquoted matches HTSQL entities using following rules:

  • Case-insensitive comparison is used to match object’s name.
  • Underscore symbol (_) can be used to match space, dash, or any other non-alphanumeric character.

For instance, test_3 matches aspects named TEST-3 and Test 3.

This matching scheme permits HTSQL identifiers to serve as valid Javascript identifiers. It also permits HTSQL URIs to be used in double-quoted XML/HTML attributes without percent-encoding.

If unquoted identifier matches two or more objects, quoted identifier must be used. For instance, in case if aspects TEST-3 and Test 3 from previous example both exist.

1.4.4. Namespaces

Aspects, functions, operators and commands have a namespace. Fully qualified object name must be unique and is defined as:

namespace ":" identifier

Namespace of an aspect corresponds to database schema.

Namspaced objects may be qualified without a namespace. In this case:
  • for aspects HTSQL tyies to resolve identifier through all visible namespaces
  • for all the rest default namespace htsql is used.

1.4.5. Aliases

Aliases are symbol names, that are defined to represent some expression. Once defined, aliases may be used in further within a query. In the resulting SQL aliases are substituted with original expression.

Aliases make code reusable within the same query and also affect output: aliases, given to an expression within a selector, are also name of result columns.

Aliases can be defined with:
  • aliasing operator as
  • aliasing function as

Note, that both return expression itself, so they can be used within more complicated expression.

Alias must be a valid identifier, not clashing with database objects or earlier defined aliases.

Alias visibility:
  • within segment, where it is defined
  • after declaration

1.4.6. Variables

Since HTSQL query is an URL, it may be used as html form action. Note, that form method POST is required, since GET method will add parameters to URL and break htsql query. Form parameters, sent to the server, may be used within htsql query expressions. For this purpose htsql syntax supports placeholders for form parameters, called variables:

"$" name

Variable name should match form parameter name. At query execution time variables are substituted with corresponding parameter value.

1.5. Encoding And Escaping characters

HTSQL uses UTF-8 encoding for query transmission and result representation.

No special escaping for non-printable characters is required, since HTSQL query string is a URI locator (as described in RFC 2396) and can be percent-encoded if required. Because of percent-encoding percent sign itself must be written in encoded form: %25.

1.6. Authorization issues

HTSQL catalog provides information about authorities (users), perspectives (roles) and privileges.

HTSQL core performs no actor’s identity check, but it is supposed to be done by authenication plugins. Those perform authenication in their specific way (depending on authenication policy and RDBMS authenication method) and pass approved authority to HTSQL core, where one of perspectives and related set of privileges are applied.

1.7. Transactions

HTSQL executes each query in separate transaction. However it’s possible to execute several queryies within single transaction: using transaction() command. Although the rule “one query - one transaction” is kept, the command allows to define embedded queries, which are executed within common transaction. Refer to Transactions Supporting Command for more details.