Description of the ECDB module

This module provides a single package, org.bzdev.ecdb, that provides an API for initializing and manipulating a relational database representing an event calendar. In addition to methods that select, insert, update, or delete table entries, instances of {@link org.bzdev.ecdb.ECDB} can generate iCalendar appointments and send them via email.

In the following the owner description is called a "summary" and the event description is simply called a "description". The "summary" should be shorter than the description. ECDB will pick the appropriate field (summary or description) based on the calendar appointment being created.

Calendar appointments include the starting date, starting time, ending date, and ending time for an event, whether there is some activity before an event and when that starts, and two optional alarms, with the times set on a per-user basis. The class will also send messages with or without calendar appointments to users to either an email address or to the user's MMS service. Each calendar appointment is tagged with fields that allow a previously sent calendar appointment to be updated.

All of the tables use a common convention for column names:

The database tables can be grouped into four categories. These are shown in the following four diagrams. In these diagrams, column names followed with "(PK)" indicate a primary key, and those whose column names are followed with "(FK)" denote foreign keys. The types are Java types, not SQL types. The Java types, which are documented because of the use of JDBC, are the following:

The tables are shown below in a series of diagrams. In some diagrams, tables shown in blue (or gray if printed with a black and white printer) are references to tables from another diagram.

The first diagram shows the tables for user data and some tables used to map cell phone numbers to the email address used by an MMS gateway provided by the user's wireless carrier:

diagram for user table and related tables

The second diagram shows the tables for event owners, locations, events, and event instances:

diagram for the owner table

The third diagram shows the tables for alarms and for a default choice for attending activities before an event:

diagram for timing

The fourth diagram shows the attendee table and tables defining a series:

diagram for the attendee table

There is a default implementation of these tables, represented as a set of Java properties saved in the standard XML format described in the documentation for the class {@link java.util.Properties}. An ECDB configuration file, desribed in the manual page ecdb(5), allows a file with this format to be loaded as well as the default. When both implement the same key, the one provided in the user-defined file is used.

Each property's key consists of a token naming some text, and optionally a token representing a database implementation, with these keys separated by a period. The SQL keys are

The SQL keys for manipulating the data base are the following (these should not have to be modified unless the tables were modified in an incompatible way or a database does not recognize the use of '?' in prepared statements). Two general keys are the following: The next set of keys are for the carrier, carrier mapping, and cellphone email tables: The next set of mappings are for the user-info table: The next set of mappings are for the owner table: The next set of mappings are for the location table: The next set of mappings are for the alarm and pre-event tables: The next set of mappings are for the event table: The next set of mappings are for the event-instance table: The next set of mappings are for the series tables: The next set of mappings are for the attendee table: The next set of mappings are provided for supporting various operations: