I don't remember you mentioning that before. If something is not getting committed to the database, that would cause the process that did the insert to see it, and none of the others. You also should not be able to see it when connecting to the database from a query tool if it is not being committed.
OK, but remember: /most/ children DO show the right data, including the one that made the insert. If only the child that made the insert showed that new data, then we'd know this is the problem, right?
You're using InnoDB tables, right? You may not be aware that MySQL's InnoDB tables use a default approach to transactions that is actually more cautious than PostgreSQL or Oracle's default. It's called "repeatable read", and the gist of it is that you don't see updates made in other processes since your last commit. There is an explanation of this here:
http://dev.mysql.com/doc/mysql/en/InnoDB_Consistent_read_example.html
This may be what is causing you grief. You can test it by issuing a "commit" in your view page right before you make the call to select all the stuff with Class::DBI. If that makes the problem disappear, then the cause of your troubles is InnoDB's fancy multi-version concurrency system. The simplest way to avoid the problem is to change the isolation level to "read committed" (which is more like what PostgreSQL and Oracle do by default) with the "set transaction" command, described here:
http://dev.mysql.com/doc/mysql/en/InnoDB_transaction_isolation.html
- Perrin
-- Report problems: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html List etiquette: http://perl.apache.org/maillist/email-etiquette.html
