Thursday, October 4, 2007

Firefox object member size limit

I encountered an issue in Firefox with my data coming back from AJAX. The object members of the XML Doc were being truncated to 4096 bytes. If this happens, you can use the function normalize(); on the object resulting from the parser.parseFromString call to have Firefox correct this. Make sure to do a browser check, so you don't get a script error in other browsers that don't have teh normalize function. IE 7 does not have normalize(), but it does not need it in this case because it does not break up the nodes into 4K chunks when you create the document from teh XML stream.

To see what's going on, we can look at the W3C spec at http://www.w3.org/TR/REC-DOM-Level-1/level-one-core.html.

"When a document is first made available via the DOM, there is only one Text node for each block of text. Users may create adjacent Text nodes that represent the contents of a given element without any intervening markup, but should be aware that there is no way to represent the separations between these nodes in XML or HTML, so they will not (in general) persist between DOM editing sessions. The normalize() method on Element merges any such adjacent Text objects into a single node for each block of text; this is recommended before employing operations that depend on a particular document structure, such as navigation with XPointers."

According to the first line in the quote above, IE 7 has the correct behavior in this regard and not Firefox. When the document is first created, the browser should not be splitting the nodes into chunks. However, the data is still accessible, even when split. It is placed in child nodes. You should be able to access it via the DOM child node functions/properties. This requires extra coding, so it much easier to just use the "normalize()" function.

MySql stored proc delimiters

When creating a stored proc in MySQL (MySQL 5.0+ supports this), unfortunatly you have to workaround delimiter issues. If you just use semicolons to terminate each line as you would in MS SQL Server, it won't work. So, I'm posting a template here to help developers. I'll use $$ as the delimitor, but you can use a different symbol if you like:

DELIMITER $$;
DROP PROCEDURE IF EXISTS `my_db`.`my_proc_name`$$
CREATE PROCEDURE `my_db`.`my_proc_name` ()
BEGIN
declare my_var_A INT;
[some more statements, each terminated by ; ... ];
END$$
DELIMITER ;$$

The first line configures your new symbol ($$) to be statement terminator. This allows us to put semicolons, the ordinary statement termintor inside our stored procedure, without MySQL trying to go ahead and start executing them as statements when we run the above script to create the stored procedure. See the line "END$$". We terminate that with our new "real" delimiter to allow MySQL to execute that block, thereby creating the whole stored procedure. Then we restore the delimiter to semicolon. Now when we execute our stored procedure, we should be using the default semicolon delimiter, and so the stored procedure will run fine, having ordinary statement terminators.