Setting up the databases
Switch to another DBMS
The quickstart ships with HSQL. HSQL provides a good way to try out the system, but isn't recommended for production. To begin the process of setting up a production system, create four empty bedework databases (read below) using PostgreSQL, Oracle, or MySQL* – all known to work well. If you're considering using another sql database system, please review the notes regarding "Unsupported databases" below.
*DBMS Recommendation
Note: as of Bedework 3.7, PostgreSQL is the preferred database system used by Bedework.
While MySQL is fully supported, there is a long-standing bug in MySQL that can lead to performance issues in Bedework.
Create four databases; check the character set
Create four databases named something like Bedework3p8, BedeworkTZ3p8, BedeworkSync3p8, BedeworkCarddav3p8. Provide full access rights to an appropriately named user such as bedework.
Your database should be set to use a Unicode format, generally UTF-8. For most European and American systems this requirement may not appear necessary at first, but eventually problems will occur with special characters introduced by users or by events from other calendar systems. For most non-European languages Unicode or some other multi-byte support is an absolute necessity.
Unsupported databases
Because we use Hibernate, we don’t support databases they don’t support. While Hibernate should make it possible to run Bedework on any Hibernate-supported database, in reality, there are problems with some systems that may require hand-editing of the schema. We expect in time to discover a workable solution to such problems.
Databases may be unsupported at the moment (or permanently) but it may still be possible to massage the schema enough to make Bedework run. We try to indicate why they are not supported and some will eventually move into the supported category.
- MS SQL Server: Partially supported but requires at least hand-editing of the schema. Has not been tried with 3.3.1 onwards. At least one problem remains, Sql Server does not follow the ANSI standard for unique indexes in that null=null for Sql Server but null is never equal to null in ANSI standard databases. This breaks some of the unique indexes in Bedework.
- MySQL version 4: Has problems in a number of areas. These are unlikely to ever be resolved. Version 4 is now old.
Developer notes
There are no checks that the application, e.g the calendar, has the same settings as the database. Databases will interpret the byte stream according to their configuration even if that does not match the configuration of the calendar server. Care in matching up all the components is critical. Those components are at least:
- The client (browser, caldav client etc)
- The servlet container (jboss, tomcat)
- The servlet (bedework)
- Jdbc settings
- The database
Bedework Enterprise Calendar, version 3.8