This section describes issues associated with LON-CAPA and a SQL database.
-The SQL database in LON-CAPA is used for catalog searches against resource - metadata only. The authoritative version of the resource metadata is Ð as - discussed Ð an XML-file on the normal file system (same file name as resource - plus Ò.metaÓ). The SQL-database is a cache of these files, and can be reconstructed - from the XML files at any time.
-The current database is implemented assuming a non-adjustable architecture - involving these data fields (specific to each version of a resource).
-1. - title
-2. - author
-3. - subject
-4. - notes
-5. - abstract
-6. - mime
-7. - language
-8. - creationdate
-9. - lastrevisiondate
-10. owner
-11. copyright
-LON-CAPA is meant to distribute A LOT of educational content to A LOT of - people. It is ineffective to directly rely on contents within the ext2 filesystem - to be speedily scanned for on-the-fly searches of content descriptions. (Simply - put, it takes a cumbersome amount of time to open, read, analyze, and close - thousands of files.)
-The solution is to hash-index various data fields that are descriptive of - the educational resources on a LON-CAPA server machine. Descriptive data fields - are referred to as "metadata". The question then arises as to how - this metadata is handled in terms of the rest of the LON-CAPA network without - burdening client and daemon processes. I now answer this question in the format - of Problem and Solution below.
-PROBLEM SITUATION: If Server A wants - data from Server B, Server A uses a lonc process to send a database command - to a Server B lond process.
-lonc= loncapa client process A-lonc= - a lonc process on Server A
-lond= loncapa daemon process
-- database command
-A-lonc --------TCP/IP----------------> - B-lond
-The problem emerges that A-lonc and B-lond are kept waiting for the MySQL - server to "do its stuff", or in other words, perform the conceivably - sophisticated, data-intensive, time-sucking database transaction. By - tying up a lonc and lond process, this significantly cripples the capabilities - of LON-CAPA servers.
-While commercial databases have a variety of features that ATTEMPT to deal - with this, freeware databases are still experimenting and exploring with different - schemes with varying degrees of performance stability.
-THE SOLUTION: A separate daemon process - was created that B-lond works with to handle database requests. This - daemon process is called "lonsql".
-So,
-- database command
-A-lonc ---------TCP/IP-----------------> - B-lond =====> B-lonsql
-- <---------------------------------/ - |
-- "ok, I'll get back to you..." - |
-- |
-- /
-A-lond <------------------------------- - B-lonc <======
-- "Guess what? I have the result!"
-Of course, depending on success or failure, the messages may vary, but the - principle remains the same where a separate pool of children processes (lonsql's) - handle the MySQL database manipulations.
-This section describes issues associated with LON-CAPA and a SQL database.
+ +The SQL database in LON-CAPA is used for catalog searches against resource + + metadata only. The authoritative version of the resource metadata is Ð as + + discussed Ð an XML-file on the normal file system (same file name as resource + + plus Ò.metaÓ). The SQL-database is a cache of these files, and can be reconstructed + + from the XML files at any time.
+ +The current database is implemented assuming a non-adjustable architecture + + involving these data fields (specific to each version of a resource).
+ +1. + + title
+ +2. + + author
+ +3. + + subject
+ +4. + + notes
+ +5. + + abstract
+ +6. + + mime
+ +7. + + language
+ +8. + + creationdate
+ +9. + + lastrevisiondate
+ +10. owner
+ +11. copyright
+ +LON-CAPA is meant to distribute A LOT of educational content to A LOT of + + people. It is ineffective to directly rely on contents within the ext2 filesystem + + to be speedily scanned for on-the-fly searches of content descriptions. (Simply + + put, it takes a cumbersome amount of time to open, read, analyze, and close + + thousands of files.)
+ +The solution is to hash-index various data fields that are descriptive of + + the educational resources on a LON-CAPA server machine. Descriptive data fields + + are referred to as "metadata". The question then arises as to how + + this metadata is handled in terms of the rest of the LON-CAPA network without + + burdening client and daemon processes. I now answer this question in the format + + of Problem and Solution below.
+ +PROBLEM SITUATION: If Server A wants + + data from Server B, Server A uses a lonc process to send a database command + + to a Server B lond process.
+ +lonc= loncapa client process A-lonc= + + a lonc process on Server A
+ +lond= loncapa daemon process
+ ++ + database command
+ +A-lonc --------TCP/IP----------------> + + B-lond
+ +The problem emerges that A-lonc and B-lond are kept waiting for the MySQL + + server to "do its stuff", or in other words, perform the conceivably + + sophisticated, data-intensive, time-sucking database transaction. By + + tying up a lonc and lond process, this significantly cripples the capabilities + + of LON-CAPA servers.
+ +While commercial databases have a variety of features that ATTEMPT to deal + + with this, freeware databases are still experimenting and exploring with different + + schemes with varying degrees of performance stability.
+ +THE SOLUTION: A separate daemon process + + was created that B-lond works with to handle database requests. This + + daemon process is called "lonsql".
+ +So,
+ ++ + database command
+ +A-lonc ---------TCP/IP-----------------> + + B-lond =====> B-lonsql
+ ++ + <---------------------------------/ + + |
+ ++ + "ok, I'll get back to you..." + + |
+ ++ + |
+ ++ + /
+ +A-lond <------------------------------- + + B-lonc <======
+ ++ + "Guess what? I have the result!"
+ +Of course, depending on success or failure, the messages may vary, but the + + principle remains the same where a separate pool of children processes (lonsql's) + + handle the MySQL database manipulations.
+ +