#Gdbm database as a semaphor how to#

However, it is deprecated since WeBWorK 2.1 in favor of the sql_single layout. This is the recommended database layout for courses created under WeBWorK 2.0. Information on The MySQL Access Privilege System and GRANT and REVOKE Syntax, consult the MySQL Manual.įor more information about managing courses using the sql layout, see the CourseAdministrationManual. The MySQL root account will work, or you can create a new user that only has these privileges. Using this database layout requires that you are running a MySQL server and have an account on that server with CREATE and FILE privileges and WITH GRANT OPTION. Each course that uses this layout will have a separate SQL database. Courses using this layout cannot be used with WeBWorK 1. The sql database layout maps all course data tables to tables in an SQL database. Sql (deprecated in WeBWorK 2.1, removed in WeBWorK 2.2) The use of GDBM databases is deprecated and the gdbm database layout will be removed in a future version of WeBWorK. GDBM databases are less scalable than SQL databases, so this layout should not be used for courses that don't require backwards compatibility. It is suitable for courses created with WeBWorK 1 and courses which must be backwards compatible with WeBWorK 1. The gdbm database layout maps all course data tables to GDBM database files in the course directory. Gdbm (deprecated in WeBWorK 2.1, removed in WeBWorK 2.2) The following database layouts are predefined in the WeBWorK configuration file nf. The only action you have to take when installing WeBWorK is to select and set a default database layout. WeBWorK ships with several predefined database layouts that provide for the situations detailed above. The database layout for a course that will only be used under WeBWorK 2 would instruct WeBWorK to use tables in an SQL database for all of the course's data tables. The database layout for a course that must be backwards compatible with WeBWorK 1 would instruct WeBWorK to use GDBM database files, stored in the course directory, for all of the course's data tables.

#Gdbm database as a semaphor how to#

The database layout infrastructure is an abstraction layer that allows it to do just that.Ī database layout tells WeBWorK how to find the course data for each data table in the course. So WeBWorK 2 needed to be able to represent course data in two very different ways. While simple, they are not particularly scalable, and the WeBWorK designers wanted to give schools the capability of using modern relational database engines like MySQL to store course data for new courses. WeBWorK 1 uses GDBM databases for storing course data. When work on WeBWorK 2 began, the designers wanted schools to be able to continue to use existing WeBWorK 1 courses under WeBWorK 2, and still be able to go back and use those same courses under WeBWorK 1. User-specific problem data for each user. Problems in each problem set (file name, weight, number of tries, etc.) Problem sets defined in the course (name, open date ,due date, etc.) User session keys (keep track of logged-in users)

They are as follows:Ĭlasslist data (user names, email addresses, student IDs, etc.) Within each course's database, there are several lists, or data tables, that contain different types of data.

3.2 sql (deprecated in WeBWorK 2.1, removed in WeBWorK 2.2)Įach WeBWorK course uses a database to keep track of course data.

3.1 gdbm (deprecated in WeBWorK 2.1, removed in WeBWorK 2.2).