InnoDB Fun

I have been working with InnoDB for the first time lately and here are a couple things I have learned so far:

1. You cannot assign a foreign key to a field if the two field types to do not match exactly. This means that if your 'user_id' field on your 'userGroup' table is unsigned and for some reason your 'id' field on your 'user' table is signed, it will not work. For instance if I have a relationship between 'applicant_id' on the 'application' table to the 'id' field on the 'applicant' table and I try to change one of the types
   

   #1025 - Error on rename of '.\sampledb\#sql-894_7bb' to '.\sampledb\applicant_applicant' (errno: 150)

   
   I got to a point where I needed to change all of my tinyint() fields to int() and I was going to have to unmap and then make the changes and then map them again. I have well over 30 relationships and I was not going to do that. The solution? Take a MySQL dump of the database and do a find/replace on tinyint(). That changes them all so they match, then just import.
   
   
2. If you try to assign a foreign key from one column to another and a row in the local table has a value that cannot be found in the foreign table, it will not work. You will receive an error:
   

   #1452 - Cannot add or update a child row: a foreign key constraint fails (`sampledb/group`, CONSTRAINT `group_ibfk_1` FOREIGN KEY (`id`) REFERENCES `employee` (`id`))

   
   This also happens if you try to add a new entry and the local_id does not match a row in the foreign table.

AJAX caching discepancy between IE and Mozilla

There is a discrepancy between Firefox and IE (actually about 1,252,238 but who's counting?) when dealing with AJAX calls. In this particular case I was trying to upload a file and check the status via AJAX. I was using Python to return the file upload status and then making interval calls to it. After hours of troubleshooting and wondering how in the world I was getting two different results from my AJAX calls between the two browsers (seeing how PHP is server-side), I realized the problem was IE which was caching the first or second call, therefore the progress never got past 0-2%. You have to pass a random number along in the URL arguments to force IE to retrieve fresh data.

403 Error After Restructuring Files

I was trying to move my site (sbiz) from /home2/sbiz to /home/sbiz so I did

cp -R /home2/sbiz /home

I then changed the appropriate lines in my httpd.conf (documentRoot) and restarted apache to be greeted with a 403 Forbidden error when accessing a page. This was an easy fix.

cp -rp /home2/sbiz /home

The '-p' switch preserves permissions. I am not sure what copying did exactly to the permissions but this was the fix.

faultString="No destination with id <\my dest id\> is registered with any service."

We have been working on a project for a few weeks now in Flex/PHP/MySQL using Doctrine as our ORM. However, after Joel dove into the world of LCDS and Hibernate we have decided to move that direction. SO, I began to research LCDS and start working through some tutorials. The first one I ran into that seemed simple enough was My First Hibernate Flex Application. I installed the LCDS package from Adobe locally and got everything setup and even got the sample apps to work just fine.

I began to copy and paste the code from the tutorial to make sure it all worked before I started tweaking and playing but once I finished I got some long winded error in a Flex alert and immediately looked at Charles to see what was going on. It was trying to access http://localhost:2037 for the "my-rtmp" channel but was failing. So I changed the port to 2038 in my 'services-config.xml'. Then I rebuilt the flex app and ran it again to get a new smaller error that said:

.....
(Command method=_error (0) trxId=3.0)
(Typed Object #0 'flex.messaging.messages.ErrorMessage')
rootCause = null
destination = "employee.hibernate"
headers = (Object #1)
correlationId = "1EA4B470-3C6E-0E12-EED6-90E1F1EE767E"
faultString = "No destination with id 'employee.hibernate' is registered w
ith any service."
messageId = "4CB7A011-7A09-3764-31CF-BE54802842D7"
faultCode = "Server.Processing"
timeToLive = 0.0
extendedData = null
faultDetail = null
clientId = "CDDF2F69-8C30-1329-9C04-90E1F1781933"
timestamp = 1.21790647145E12
body = null
.....

At that point I really didn't know what to do. I noticed a lot of other people had that same error and no one posted a solution. Joel told me to check my Tomcat terminal and see what was happening so I restarted and took a look and saw:

....
INFO: Starting Servlet Engine: Apache Tomcat/6.0.14
[LCDS] [WARN] Throttle outbound policy 'REPLACE' found on message destination 'hibernate-employee'. The 'REPLACE' throttle outbound policy has been deprecated. Please remove it from your configuration file.
[LCDS] [ERROR] Error instantiating application scoped instance of type 'flex.data.assemblers.HibernateAssembler' for destination 'hibernate-employee'.
java.lang.UnsupportedClassVersionError: Bad version number in .class file
....

So I tookout the tag that had the 'REPLACE' throttle policy in it in 'data-management-config.xml' and I began google-ing the second error about the bad version number. It turns out that I built the Employee.class file for JRE 1.6 while Tomcat was running on 1.4. So I rebuilt Employee.class to 1.4. Those two errors were now gone.

FINALLY, I restart Tomcat again and I get the following in the terminal:

...
[LCDS] SocketServer 'my-rtmp-SocketServer' is starting.
[LCDS] SocketServer 'my-rtmp-SocketServer' failed to pre-validate desired socket settings for BindSocketAddress: 0.0.0.0:2038
java.net.BindException: Address already in use: JVM_Bind
at java.net.PlainSocketImpl.socketBind(Native Method)
....

Hmm... so port 2038 is in use by JVM_Bind and trying to be used again by our 'my-rtmp' channel. I remembered changing that somewhere earlier....ah yes! services-config.xml! I opened that bad boy up and changed the 'my-rtmp' channel to use http://localhost:2039, restarted Tomcat, rebuilt my Flex app and BOOM - The employee table populated. I am not sure where the discrepancies lie between the different ports and what causes them but everything is working now as planned.

So... I am not sure if the previous errors were causing the same thing since the error stayed consistent after I fixed each problem but the final solution was changing the port to 2039. If you are having problems with this, check your Tomcat terminal and get some debugging info.