The majority of the coding modifications have yet to be made, but the database switch has already occurred. In the process of moving from MS Access to MySQL I discovered a few settings that would be helpful should this action need to be performed for other applications. These settings should enable similar applications to be moved with minimal modification to the programming.

First, let’s review some settings related to the MySQL ODBC driver. The settings are relevant to all versions of the driver, but the name of the setting may be different on different versions (I’m using 5.1.6). Here are the options which should be selected:

• Return matched rows instead of affected rows
• Treat BIGINT columns as INT columns
• Enable safe options

The following information relates more generally to changes that may have to be made in the code:

• MySQL doesn’t really support server-side cursors so the ODBC drivers fakes it. This is, mostly, fine except that some properties of the Recordset object are not available (namely RecordCount). In order to get full cursor support you should change the location from the server to the client (adUseClient or the literal value 3).
• ASP doesn’t understand non-signed integers. This causes problems when performing operations using these values unless you manually type the value in your script, e.g. scriptvar = CInt(objrs("dbcol")). The other solution is to make all integers signed. Otherwise you will see the error: Variable uses an Automation type not supported in VBScript.
• Related to the above is the usage of values from the database in comparison functions. VBScript variables are typed (e.g. integer, string, boolean, etc.). Though you can’t specify the type during variable instantiation (with Dim) VBScript does pay attention to type when performing comparisons. When two variables of different types are compared you will get a “Type mismatch” error. The resolution is to Ctype your variables if you run into this type of error.
• Finally, check your SQL statements for any VBA function calls. These will either have to be modified into MySQL-compatible function calls or removed from the SQL code altogether.

There are a number of issues that may be encountered when attempting to convert an ASP-based application from MS Access to MySQL. The issues addressed here are only those relevant to this particular application. Other applications may require additional or different solutions and settings.

Resources:

• MS Access to MySQL migration script
• MySQL Developer Zone: MySQL CursorTypes, LockTypes, and CursorLocations
• MySQL 5.1 Reference Manual: 21.1.4. Connector/ODBC Configuration
• MySQL Forums: type confusion in asp
• MySQL Lists: Problem with RecordCount with ASP & MySQL

From what I can tell, when CakePHP specifies the values for all columns when it creates a new record. A column with a defined default that is not specifically set by the user is manually set by CakePHP (rather than let MySQL handle defaults upon record insertion). But CakePHP doesn’t understand the CURRENT_TIMESTAMP keyword and so treats it as a string and wraps it in quotes. This breaks the resulting INSERT statement and you receive an error:

Incorrect datetime value: ‘CURRENT_TIMESTAMP’

Interestingly, columns that are named “created” and “modified” receive special handling by CakePHP. These columns are treated like auto-update columns by CakePHP and it sets them as expected. With the special handling of these columns in mind it is possible to get around the CURRENT_TIMESTAMP bug by following the recommended settings for created/modified columns, i.e. specifying the field as DATETIME with a default of NULL. CakePHP will automatically update the columns when inserting/updating records.

References:

• MySQL Reference Manual: 10.3.1.1. TIMESTAMP Properties
• CakePHP Cookbook: 3.7.2.3 created and modified

Data Collection Hassles

For the past few years the Assessment team has sent out a large batch of items in what we call pilot tests. These tests are used to gauge the effectiveness of assessment items. The format consists of an item followed by a set of questions about the item (Was there anything confusing?, Did the picture help?, Is answer A correct?, etc.). The questions have set answers (Yes, No, Not Sure) and/or a space for the student to provide a short written response.

In previous years we have used temporary workers to input the student responses into the Items Utility. This proved to be extremely slow and relatively expensive.

Last year we attempted a new method of data collection using an automated system to capture the Yes/No/Not Sure responses. This system used optical mark recognition (OMR) and required the packets to be formatted in a consistent manner on each page. Formatted in this way we could create a master file indicating how to judge answer selection. This proved fairly successful, though we did have to outsource the scanning to a third party. The results of the scan came back as Excel documents. A little PHP coding and I easily imported the scanned data into the Items Utility. The main drawback was that we still had to hire temps to enter the written responses.

This year we embarked on a new automated scanning system for the Yes/No/Not Sure responses that proved even better than in previous years. This system uses an in-house scanner and design software. A lot of prep work had to be performed by the researchers to set up their test packets. And we did have to use specific printers to produce the packets. But I believe in the end we saved money, particularly since the majority of the leg work had already been done in figuring out how to import the data into the utility. The only snag is that we again had no way of capturing the written responses electronically.

However, one of the benefits to the new system is that in addition to creating a data file for the Yes/No/Not Sure values it can produce images of the scanned regions. At first I thought maybe we could find some way of performing character recognition on the scanned images. Unfortunately, there’s just no economical way to do that on hand-written text. So our only real option was, again, transcription by a human being. Past experience with the time and money required made the option unpalatable and we were likely going to just move ahead without the hand-written data.

Enter the Turk

Amazon recently released a web-based service, Mechanical Turk (MTurk), that provides access to a distributed workforce. The service provides a means of creating what Amazon calls “Human Intelligence Tasks” (HITs), tasks that are currently too complex for a computer but ideally suited for your average person. We decided to try the service out for transcription of the written responses.

Since MTurk is web-based, the HITs are set up as web pages. An online editor makes setting up HIT templates fairly simple, though it helps to know a bit of HTML. Each template consists of instructions and a form where the worker enters the requested information. It’s up to the requester to determine the amount paid for each HIT completed (starting as low as one cent). Amazon tacks on an overhead fee for each HIT that is completed by a worker and accepted by the requester.

The template uses variables to fill in each HIT with unique information. Once the template is set up you provide a data file that contains the variable data. MTurk then publishes your HITs on a public interface where anyone in the world with an internet connection can perform the work.

Using MTurk

As I said, the program we used to scan the packets is able to save scanned regions as images. These images were organized such that we could easily determine the packet/student/item combination based solely on the file name and directory in which the image was located. This information is all we needed to insert data into the Items Utility, and thus provided an easy identifier to use with MTurk.

To minimize the amount of time a worker spends on each HIT it’s good to try and have all the data the user needs on the screen. Since a MTurk HIT is a web page it can reference images located on external servers. I used URLs for the image scan as values for the template variables. The HIT displayed the image side by side with a text area where the workers could input the transcribed text.

Initially I thought to just link to the original images. A quick test, however, and I realized that the size of the images would be a problem. The images were larger than needed and any bandwidth constraints on the worker end would significantly increase the time per HIT. Smaller files were needed, and to save space I thought to dynamically resize the images using PHP. A sample proved the folly of this idea. Our system resources are limited and the processing power and memory required to enable this for more than a few simultaneous workers caused the HITs to load slower than if we hadn’t resized to begin with. In the end we decided to resize all images, a scenario we had avoided due to space constraints. The smaller image would be referenced on each HIT with a link to the full size in cases where a zoomed view might be benefitial.

Since Amazon tacks on a handling fee for each HIT I attempted to organize our HITs in a way that would work out best for both us and the workers. We needed HITs that could be completed quickly but that also collected sufficient data so that the cost-per-HIT would balance out against the amount of work required. Plus we were concerned about providing equitable pay for the work being done. Based on our testing we were able to make a determination of how many images per HIT and at what rate would keep our fees acceptable while also resulting in an equitable wage.

Our due dilligence paid off. We had 48,351 HITs comprised of 193,401 images. The work was completed within a couple of days, which was beyond my wildest estimates. The amount paid and the time taken to complete the work was significantly less than what we would have paid to hire traditional temporary workesrs to do the same.

Once the work was complete MTurk provided a data file that included the original data along with the worker input, all the information we needed to import the data into the utility.

Wrapping Up

While this was a bit of a learning process, using MTurk to transcribe this data proved successful. I fully expect to use this system in the future. This has been more of a review of the process, but there were a few technical aspects involved. Rather than go into detail on these I’m providing links to the files involved which should provide sufficient information in that regard (except for perhaps the import script).

• PHP Script to Generate a List of Files
• PHP Script to Resize Images
• Data Set Sent to MTurk
• MTurk HIT Template
• Result Data Set Provided by MTurk
• Simplified Result Data Set
• PHP Script to Import Data

I was having some problems, however, because the table that needed to be updated uses a mutli-column primary key. Normally I would select the relevant rows using a JOIN. Unfortunately, you can’t update the results of a JOIN. How then to select the relevant rows?

Turns out it’s easier than I thought. You can still use the WHERE ... IN clause, you just specify all of the columns that satisfy the condition: UPDATE table ... WHERE (key_column1, key_column2) IN (SELECT key_column1, key_column2 FROM ...).

I did not see any information about this functionality in the MySQL Reference Manual (1, 2).

I created a series of SQL statements to run in MySQL that will convert the data from the packet_item_records and miscon_packet_refs tables to the packet_students, packet_data, and miscon_packetdata_refs tables. After the conversion I updated any pages that referenced the old data structure. So far in testing the data seems to have converted perfectly.

Minus one issue. Multiple selections for the answer choice questions (A, B, C, D) from 2006 were recorded as a generic Multiple rather than Y+NS, N+NS, etc. This value is not represented in the updated data format or on the data entry forms or summary tables. Rather then spend too much time addressing this issue I’m going to leave these values empty for now. I don’t expect this to be a problem since the researchers are focused on data for the current pilot and field tests. Also, I’m keeping the old version of the piloting data and scripts that interact with it online in case it’s needed.

Purpose and Need

As I mentioned, we’re using the full text search capability of MySQL as the core of our search functionality. By default, MySQL performs a natural language full text search. This mode has a few restrictions that can affect the results that are returned, but most notable for our purposes is that a word provided by the user must match exactly a word in the record. What this means is that records with a variation of the word (such as a plural when a singular was provided) will not be returned. For example, if you search for “atom,” MySQL will not return records that have “atoms” or “atomic” but not “atom.”

I’ve found the easiest way to address this limitation is by performing the search using the keywords as typed, but then adding on results that have matches to the stem of the keywords. By using these two full text search methods in conjunction we can get the best results for our user.

Finding the Stem

The hardest part of this whole process was determining a way to find the stem for a word. Initially I developed a simple function that stripped plurality from a word. Is was simplistic, but provided a good sample of how effective stemming could be. A little more research led me to a PHP extension that uses an established algorithm to determine a word stem. The extension is available from the PECL PHP library and is called “stem.” Installation is simple. On *nix you first install the extension:

sudo pecl install stem

Next, update the php.ini file to enable the extension by adding the following line:

extension=stem.so

Finally, restart the web server for the new setting to take affect:

sudo /etc/init.d/apachectl graceful

On Windows you first download the dll from pecl4win.php.net (PECL installation actually involves compiling the extension binary which is not quite as straightforward on Windows). Place the dll in your php/ext directory. Next, update the php.ini file to enable the extension by adding the following line:

extension=stem.dll

Finally, restart IIS for the settings to take affect.

How to Use

Performing a search with stem expansion using MySQL’s full text search functionality is actually quite easy. First we need to break the search terms up so that we can stem them. To do this we need to isolate each word in the search phrase. We can do this by splitting the search phrase into an array. It’s impossible to know exactly what the user will type, so we can be greedy and use something like:

$araKeys = preg_split('/\W/', $strSearch);

Then we need to modify each keyword so that we have its stem:

$araKeys = array_map('stem', $araKeys );

Recombine the keywords into a new boolean search phrase:

$strSearchBool = join('* ', $keysArray) . '*'

Finally, we combine the original natural language search with a boolean mode search:

MATCH(fulltext_index_columns) AGAINST ('$strSearch') OR MATCH(fulltext_index_columns) AGAINST ('$strSearchBool' IN BOOLEAN MODE)

Order the results by the sum of the relevance values for the full text searches and you’re done:

ORDER BY (MATCH(fulltext_index_columns) AGAINST ('$strSearch')) + (MATCH(fulltext_index_columns) AGAINST ('$strSearchBool' IN BOOLEAN MODE)) DESC


The two combined provides a good sense of how well a result matches. Records that match the entered search terms exactly will bubble to the top of the list since they match on both the natural language and boolean searches. Records that match only on the stem-based boolean search will come next, and the more words they match the higher in this secondary list they will be. These stem-based matches would not be returned by the natural language search since the exact search terms were not present in the records.

Future Development

MySQL has stated a desire to enhance full text searching with stem and proximity information. The implementation of these features will negate the need for this to be done via the hack described above. At that point this extra code should be removed, though I doubt it will cause problems with the search results if left in place.

MyISAM Recovery

MyISAM is a nice format for speed and has support for functionality not available in other MySQL storage engines (such as full text search). Unfortunately MyISAM is not nearly as robust as InnoDB. Since the data files are dealt with directly sans transactions a system crash can cause table corruption and loss of data (particularly is an INSERT/UPDATE operation were in progress). To ensure that the tables have not been corrupted at any time we can set myisam-recover=BACKUP,FORCE. This will tell MySQL to check a MyISAM table when it is opened, repair it if necessary, and make a backup of the table.

There are some drawbacks with this setting. First, if a row is corrupted the data from that row could be lost. That’s why we use the BACKUP option. Also, there can be a performance hit due to recovery operations, particularly if a large number of tables have to be repaired simultaneously. Not to mention that the recovery check is done every time a table is opened.

Another method of checking the MyISAM tables we should consider is a cron job that checks the tables outside of MySQL. This would give us the benefit of automated repair (or at least notification) while mitigating possible performance bottlenecks.

References:

• MySQL Reference Manual: 5.1.2. Command Options
• MySQL Reference Manual: 5.1.3. System Variables
• MySQL Performance Blog: Using MyISAM in production
• MySQL Performance Blog: MySQL Crash Recovery

Thread Cache

MySQL assigns a thread to each connection made by a client. Thread creation/destruction can be a relatively expensive process, but MySQL gets around this by implementing thread caching. Thread caching allows MySQL to reuse a thread once a connection is finished with it. A thread is not destroyed unless the number of active threads exceeds the thread cache limit. The thread cache does not have to be large enough to handle all simultaneous connections, particularly since maintaining a thread uses up system resources. The cache should be large enough, however, such that the number of threads created is small. Check the Threads_created server status variable.

We currently do not have thread caching enabled. Our threads created is at 60,000, which is extremely high (~460 per day). Unless you set up persistent connections to MySQL using the pconnect() function PHP will open/close a connection each time a web page is loaded. I’m going to go with a value of 20. Assuming maximum concurrent connection could reach 25 this provides plenty of cached connections for average usage. If the number of threads created does not budge past the cache limit we should consider lowering the value somewhat to free up resources.

For an hint of how important thread caching is, see MySQL, Linux, and Thread Caching and Optimize MySQL: The Thread Cache.

References:

• MySQL Reference Manual: 7.5.7. How MySQL Uses Threads for Client Connections
• MySQL Performance Blog: What to tune in MySQL Server after installation

Table Cache

Opening a table can be a slow process as data descriptors are created and file headers are modified. To mitigate this MySQL uses a file-based table cache that maintains a table in an open state for future connections. A unique entry in the table cache is required for each concurrent access to a table (multiple users or multiple accesses by a single user in a query). Every time a table is opened an unused table cache entry for that table is sought. If none is found a new one is created. Once the table cache reaches the limit specified by the table_cache variable MySQL has to close old cached connections before opening new ones, adding even more time to table access. MySQL recommends sizing the table cache so that it can handle the largest number of concurrent connections multiplied by the largest number of tables accessed by a single query. This is at the high end. You can start lower and watch opened_tables to see if the table cache is constantly swapping out tables. The faster opened_tables rises the more urgently the table cache needs to be increased.

One caveat to consider when setting the table cache is the per-process file pointer limit. Each cache entry is associated with MySQL. If the number of files held open by MySQL exceeds the limit allowed by the operating system no further files can be opened. MySQL does not fail gracefully in this situation and may, according to the documentation, “refuse connections, fail to perform queries, and be very unreliable.” You can find the file usage limit by issuing the following command cat /proc/sys/fs/file-max. It’s very unlikely we’ll have a problem; the current value indicated by this command is 50569. But the results of going over this limit appear to be fairly severe for MySQL, so it’s a good idea to check.

The current table cache of is set to 160 and is full, but the value of opened tables is rising slowly. Still, our maximum concurrent connections has already hit ten, so I believe we could easily see the table cache get overwhelmed once the database is exposed to a larger traffic base. If we assume maximum concurrent connections of 25 and a crazy join of 10 tables then we’re looking at a table cache of around 250. I’ll start with this number and watch the opened tables stat to see if the cache needs to go higher or can be lowered.

References:

• MySQL Reference Manual: 7.4.8. How MySQL Opens and Closes Tables
• MySQL Performance Blog: What to tune in MySQL Server after installation
• Database Journal: Optimizing the mysqld variables

Temporary Tables

Temporary tables may be used by MySQL when performing queries. By default these tables are created in memory. However, there are two situations in which a temporary table will be written to disk, resulting in a bit of a performance hit: when a temporary table grows beyond the maximum allowed; and when a condition exists that prevents the use of a temporary table. The former situation is one determined by the tmp_table_size/max_heap_table_size parameters. The latter is determined by table and query structure. tmp_table_size is specific to temporary tables while max_heap_table_size applies to all memory tables, so make sure that max_heap_table_size is at least as large as tmp_table_size.

The allowable size of temporary tables should be large enough to avoid writing to disk where possible, but small enough that memory is not eaten up. There is no provision to limit the number of temporary tables stored in memory. If there are many simultaneous connections and each connection is working with a large temporary table memory could be filled rather quickly.

You can determine whether or not your temporary tables are being created in memory by looking at the number of temporary tables that had to be written to disk (Created_tmp_disk_tables). Ours is hovering around 50% of the total number of temporary tables (Created_tmp_tables), but this isn’t enough information to make a decision about the optimal setting for tmp_table_size. What we don’t know is the reason a table is written to disk. That’s something that can only be determined using the EXPLAIN statement.

Since the number of disk-based temporary tables is relatively high I’m going to increase the maximum size allowed for memory-based tables and see if that improves things.

References:

• MySQL Reference Manual: 5.1.3. System Variables
• MySQL Reference Manual: 5.1.5. Status Variables
• MySQL Reference Manual: 7.5.9. How MySQL Uses Internal Temporary Tables
• Database Journal: Optimizing the mysqld variables

Query Cache

For SELECT queries, the speed of the response can be affected by factors such as query structure and which columns are indexed. MySQL is able to provide fast results for often-run queries by storing the results in the query cache. The first time a query is run the query and its result set are stored in the query cache. Subsequent runs of the exact same query will pull the results from the cache (so long as the cached entry is available). There are some qualifications for the query cache to be used successful. First, a query must match in a binary manner in order for MySQL to use a cached query. This means a query must match character for character in a case-sensitive way with the previous run. Second, the query results must not exceed a defined size (1MB by default) or it will not be cached.

To enable the query cache set query-cache-type = 1 and give query_cache_size a value. The best size of the query cache is a guessing game. I’m starting with a value of 32M. Though we’re likely to see little performance improvement on the web-based applications due to constant table updates (which invalidates any cached results for that table) we should see decent performance improvement for more static tables such as those used to serve dbBOL. As a result, judging the efficiency of the cache based on the usage data provided by MySQL will be somewhat difficult. Still, I would expect to see a relatively high value for Qcache_hits when compared to Qcache_inserts and a low value for Qcache_lowmem_prunes. It’s also important to keep an eye on Qcache_free_blocks in order to ensure the cache memory is not fragmented. This number should remain low and can be improved temporarily by issuing a FLUSH QUERY CACHE statement, which will “defragment” the query cache.

One thing to keep in mind is that any cached query will be dropped if the table it references is updated. Tables that are updated often should include the SQL_NO_CACHE attribute in any SELECT queries to prevent caching. This will help prevent the extra overhead of storing and dropping queries from the cache when those caches can rarely be reused.

References:

• MySQL Reference Manual: 7.5.4. The MySQL Query Cache
• MySQL: A Practical Look at the MySQL Query Cache
• Database Journal: MySQL’s Query Cache
• Whatever….: mysql query cache

Key Buffer

MySQL says this is one of the most important performance tuning variables and recommends allocating as much memory as possible. However, since the key buffer is stored in RAM a setting should be used that (in consideration with other settings) won’t cause the server to page memory. MySQL also recommends that the key_reads/key_read_requests be less than 0.01.

The MySQL Performance Blog recommends up to 40% of your system memory, taking into account the size of the MyISAM table indexes and available memory.

Currently the setting for this parameter is 16M and our key_reads/key_read_requests are very low (0.0002). So right now we seem to be doing great in regard to this value, but since MySQL recommends a high value I’m going to increase this to 24M or about 4.7% of system memory. Though this value is below the roughly 58M that the table indexes add up to, the maximum portion of the key buffer that has been used at any one time so far is only about 70% (based on a block size of 1M and Key_blocks_used showing 11K, meaning roughly 11M of 16M in the current setup).

Due to how MySQL uses the indexes, we should be O.K. with a key buffer size smaller than the sum of the indexes. As I understand it, MySQL divides indexes into blocks which allows MySQL to only access the part of an index it needs. Only used portions of a particular index need to be stored in the key buffer. Since some of the tables in the database are rarely (if ever) used their indexes won’t add to the overall key buffer usage.

Special note: some tables have rather large indexes. These tables should be reviewed to determine if any optimizations to the table structure can be made.

References:

• MySQL Reference Manual: 5.1.3. System Variables
• MySQL Reference Manual: 7.4.6. The MyISAM Key Cache
• MySQL Reference Manual: 7.5.2. Tuning Server Parameters
• MySQL Performance Blog: What to tune in MySQL Server after installation
• Database Journal: Optimizing the mysqld variables

Sort Buffer

The sort buffer is used whenever ORDER BY or GROUP BY is used in a query. If the amount of memory required to perform an operation of this type exceeds the value of sort_buffer_size MySQL has to sort the current working set, write the data out to disc, and start another working set. So not only do you have the problem of sorting parts of the result set separately, but then those groupings have to be combined on disc and sorted. Conceivably, then, a larger value would be beneficial. You can see how often a sort buffer has to be written out to disc and combined with additional buffered data by looking at the Sort_merge_passes status variable.

The sort buffer is a per-connection setting, meaning that each connection can allocate the amount specified by this value. As a result, care should be taken when setting this value in order to avoid eating up too much memory. Also, the MySQL Performance Blog has benchmarks showing a larger sort buffer actually hurting performance. With all this in mind it may be wise to use a relatively low value in the server settings and specify a larger value when necessary for a specific connection. Also, it may be advisable to perform some testing in various scenarios to see if there is an optimal minimum to cover most situations.

Still, MySQL recommends using a larger value to help improve sorting. Our current value was 512K. Our merge passes appear to be rising steadily (though not severely). So for now I’m doubling the value.

References:

• MySQL Reference Manual: 5.1.3. System Variables
• MySQL Reference Manual: 5.1.5. Status Variables
• MySQL Reference Manual: 7.2.11. ORDER BY Optimization
• MySQL Performance Blog: How fast can you sort data with MySQL?
• MySQL Performance Blog: Are larger buffers always better?
• Database Journal: Optimizing the mysqld variables

Read Buffers

MySQL uses read buffers when accessing table data. There are two settings to pay attention to here: read_buffer_size and read_rnd_buffer_size. MySQL allocates read_buffer_size when a sequential scan is performed. A sequential scan is when every row in a table is read and typically would be done when an index can’t be used to satisfy a query. MySQL allocates read_rnd_buffer_size when tables rows are read based on a key sort.

As with the sort buffer, the read buffers are a per-connection setting. So setting this value with consideration of our available memory is important. Plus, the MySQL Performance Blog has found some performance issues with larger values for these settings, similar to the issues with the sort buffer. Once again these are variables that may be best increased as needed. And again, testing should be done to find an optimal minimum.

Since these settings can show something of a benefit we want to increase the value if possible. Until further testing can be done on our system, however, I’ll keep these values below the theorized threshold of decreasing returns, 256K (at least until further testing and optimization can be done with our own system).

References:

• MySQL Reference Manual: 5.1.3. System Variables
• MySQL Reference Manual: 7.5.2. Tuning Server Parameters
• MySQL Performance Blog: MySQL: what read_buffer_size value is optimal?
• MySQL Performance Blog: Are larger buffers always better?
• MySQL Performance Blog: What exactly is read_rnd_buffer_size?
• MySQL Performance Blog: Read Buffers, mmap, malloc and MySQL Performance
• In August Productions: Read Buffer performance hit
• Database Journal: Optimizing the mysqld variables

InnoDB

The MySQL Performance Blog recommends a number of settings for enhancement of InnoDB performance. After much consideration, however, I believe it may be best if we forgo usage of the InnoDB storage engine where appropriate. I have a few reasons for this opinion

1. InnoDB tables are more resource intensive due to their use of transactions.
2. Fulltext indexing, a feature of MySQL that we have come to depend on for a number of applications, is not currently available for InnoDB tables.
3. Our current applications do not generally require the added safety of a transactional database.

If we do decide in the future to implement InnoDB for a future application (such as an online ordering system) we should revisit the optimization settings.

To ensure that tables are MyISAM by default I have set default-storage-engine = MyISAM. This can be overrode by specifying the table engine when creating a new table or by altering a table.

Fin

Once settings changes have been made to /etc/my.cnf restart the server and check the server variables (SHOW GLOBAL STATUS or use PHPMyAdmin) to ensure all settings have been implemented correctly.

Also, see my earlier post on optimization.

Processes that shape the earth/Plate Tectonics Version II (PT)) which shares a number of misconceptions with another topic (Earth Science: Processes that shape the Earth / Plate Tectonics (EP)).

Problem: She changed the topic of those misconceptions believing it would be available to both topics. Once she realized this was not the case, she changed the topic back, but the numbering was off.

Solution: She provided me a list of which misconceptions were out of sync. Because adding a misconception involves updating multiple tables I actually had to add the misconceptions through the Item interface and then change the numbering on the backend.

Conclusion: The conclusion is that the conclusion is pretty obvious. This functionality needs to be revised. Changing the topic of a misconception has considerable consequences throughout the Items utility, so I think it may be necessary to add an additional step to this process. For example, have the current topic displayed along with a check box and a disabled/hidden topic menu. Then use the checkbox to enable/disable the menu and possibly some kind of textual warning (“Changing this is likely to break something.”).

Another note is that the ‘code’ column denoting the numbering sequence is not a unique column so we could have the numbering be editable on the interface. Although this could have some duplication complications.

I also found it strange that when submitting a new misconception, there is no notification and you are not redirected back to the miscon list. I found out the hard way that once you submit a misconception you are essentially in edit mode (not Add New Miscon anymore) and any changes made are being made to the record you just added. It wasn’t obvious to me the difference between Add and Edit mode.

I’m sure Mr. Sweeney can provide details of this request procedure upon his return.  The demographics script is working fine, but the demographics data is most likely out if date.  Cari indicated the demographics data will not be needed for a few weeks.

This names were confusing so I renamed them to registrant_list.php and registrant_list_demo.php (demographics).

I added a filter (by year) to limit output results.  However it is not technically filtering by year.  There was already a date limit written into the existing query (2007-04-27, I think) which I used as the start range marker for 2007.  The start range for 2008 is 2008-01-01.  The messy part is that everything prior to 2007-04-27 is marked as 2006 in the filter when in fact the records only go back to 2007-04-17.  I expect to be working on this script again in the near future (see “Updates to field test registrant_list_demo”) at which point I will probably change the filter to just ‘Prior’.