I just downloaded TJDO and tried to walk through the tutorial on the project page.
But when executing, the VM throws me this stacktrace:
log4j:WARN No appenders could be found for logger (com.triactive.jdo.store.DatabaseAdapter).
log4j:WARN Please initialize the log4j system properly.
Exception in thread "main" javax.jdo.JDODataStoreException: Cannot find probe table DELETE_ME1117657624588
at com.triactive.jdo.store.ProbeTable.findSchemaName(ProbeTable.java:50)
at com.triactive.jdo.store.StoreManager.<init>(StoreManager.java:200)
at com.triactive.jdo.store.StoreManagerFactory.getStoreManager(StoreManagerFactory.java:44)
at com.triactive.jdo.PersistenceManagerImpl.<init>(PersistenceManagerImpl.java:82)
at com.triactive.jdo.PersistenceManagerFactoryImpl.getPersistenceManager(PersistenceManagerFactoryImpl.java:566)
at com.triactive.jdo.PersistenceManagerFactoryImpl.getPersistenceManager(PersistenceManagerFactoryImpl.java:542)
at de.test.PersonPersister.main(PersonPersister.java:26)
Google does not give any hits on the exception message. Any solutions?
Cheers, lirion
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
TJDO creates the probe table solely to determine
the name of your current schema. The probe table
DELETE_ME... has been created successfully
(supposedly) but it did not show up in a
subsequent call to DatabaseMetaData.getTables(),
which shouldn't be possible.
Mike
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Mike's suggestion of driver issues is most likely, however if nothing is immediately obvious about the driver (e.g. mismatch between driver and DB), you might try configuring logging to see what you can see. Perhaps there's a non-fatal warning that would explain the problem. First try INFO level and see if anything odd pops up... DEBUG is pretty verbose for most purposes, but you're not really getting started (presumably), so wading through a debug-level log shouldn't be too bad either...
The exception message itself is pretty unique to TJDO, and it's a relatively unusual problem... If you figure it out, please let us know the gory details.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The JDBC driver could be working quite nicely for all the JDBC methods you happened to have used in the past, and be broken for the particular method that TJDO needs at this point (or broken in combination with a particular version of the DB). As Mike noted, TJDO is trying to use DatabaseMetaData.getTables(), which is standard JDBC but is probably not actually used all that much. In particalular, we're using:
DatabaseMetaData.getTables( null, null, 'DELETE_ME***', null)
which is supposed to return a result set of all accessible table descriptions for any table with that name in all schemas (and all catalogs, if the DB supports catalogs). It wouldn't surprise me at all if the driver were to be broken here, perhaps just when the schema is null.
Eyeballing the code in ProbTable.java, there are really only 4 possibilities total:
1) the drive is broken for the particular call (50% chance)
2) The DB is unwilling to supply the information requested in the call, perhaps due to lack of privilege (49% chance)
3) somehow a different connection is being used between create of the probe table and request for its metadata and the connections are for different users or different DBs or the creation of the probe table was not committed (.999% chance) (I've actually managed to do something like this once, though not with TJDO.)
4) somehow something has intervened and deleted the probe table between creation and test ( .001 percent chance)
I'm guessing that the DELETE_ME*** table is being left behind in the database, but if not, you could manually create a table with that name. Then you could throw together a quick-and-dirty test that would validate that it's one of the first two problems (and be available to test alternate drivers/DBs).
We (TJDO) really ought to have a driver validator for diagnosing problems like this, it ought to be pretty simple. I'll see if I can start one this weekend, but I'm not promising...
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi,
I just downloaded TJDO and tried to walk through the tutorial on the project page.
But when executing, the VM throws me this stacktrace:
log4j:WARN No appenders could be found for logger (com.triactive.jdo.store.DatabaseAdapter).
log4j:WARN Please initialize the log4j system properly.
Exception in thread "main" javax.jdo.JDODataStoreException: Cannot find probe table DELETE_ME1117657624588
at com.triactive.jdo.store.ProbeTable.findSchemaName(ProbeTable.java:50)
at com.triactive.jdo.store.StoreManager.<init>(StoreManager.java:200)
at com.triactive.jdo.store.StoreManagerFactory.getStoreManager(StoreManagerFactory.java:44)
at com.triactive.jdo.PersistenceManagerImpl.<init>(PersistenceManagerImpl.java:82)
at com.triactive.jdo.PersistenceManagerFactoryImpl.getPersistenceManager(PersistenceManagerFactoryImpl.java:566)
at com.triactive.jdo.PersistenceManagerFactoryImpl.getPersistenceManager(PersistenceManagerFactoryImpl.java:542)
at de.test.PersonPersister.main(PersonPersister.java:26)
Google does not give any hits on the exception message. Any solutions?
Cheers, lirion
Forget to say that I'm trying to use a MySQL (3.23.38 -- ancient, I know...) database running on localhost.
This points to a problem with your JDBC driver.
TJDO creates the probe table solely to determine
the name of your current schema. The probe table
DELETE_ME... has been created successfully
(supposedly) but it did not show up in a
subsequent call to DatabaseMetaData.getTables(),
which shouldn't be possible.
Mike
Mike's suggestion of driver issues is most likely, however if nothing is immediately obvious about the driver (e.g. mismatch between driver and DB), you might try configuring logging to see what you can see. Perhaps there's a non-fatal warning that would explain the problem. First try INFO level and see if anything odd pops up... DEBUG is pretty verbose for most purposes, but you're not really getting started (presumably), so wading through a debug-level log shouldn't be too bad either...
The exception message itself is pretty unique to TJDO, and it's a relatively unusual problem... If you figure it out, please let us know the gory details.
The log gives nothing about any warnings, just these five lines:
2005-06-02 11:30:44,981 [main] INFO com.triactive.jdo.store.DatabaseAdapter Adapter initialized: MySQLAdapter, MySQL version 3.23.38-nt major 3 minor 23
2005-06-02 11:30:45,021 [main] INFO com.triactive.jdo.store.BaseTable Creating table: null.DELETE_ME1117704645011
2005-06-02 11:30:45,031 [main] DEBUG com.triactive.jdo.store.AbstractTable Time = 10 ms: CREATE TABLE DELETE_ME1117704645011 (UNUSED INTEGER NOT NULL)
2005-06-02 11:30:45,031 [main] INFO com.triactive.jdo.store.BaseTable Dropping table: null.DELETE_ME1117704645011
2005-06-02 11:30:45,031 [main] DEBUG com.triactive.jdo.store.AbstractTable Time = 0 ms: DROP TABLE DELETE_ME1117704645011 CASCADE
I think the JDBC driver works correctly, I used the driver with the mysql-connector jar before without any problems.
The JDBC driver could be working quite nicely for all the JDBC methods you happened to have used in the past, and be broken for the particular method that TJDO needs at this point (or broken in combination with a particular version of the DB). As Mike noted, TJDO is trying to use DatabaseMetaData.getTables(), which is standard JDBC but is probably not actually used all that much. In particalular, we're using:
DatabaseMetaData.getTables( null, null, 'DELETE_ME***', null)
which is supposed to return a result set of all accessible table descriptions for any table with that name in all schemas (and all catalogs, if the DB supports catalogs). It wouldn't surprise me at all if the driver were to be broken here, perhaps just when the schema is null.
Eyeballing the code in ProbTable.java, there are really only 4 possibilities total:
1) the drive is broken for the particular call (50% chance)
2) The DB is unwilling to supply the information requested in the call, perhaps due to lack of privilege (49% chance)
3) somehow a different connection is being used between create of the probe table and request for its metadata and the connections are for different users or different DBs or the creation of the probe table was not committed (.999% chance) (I've actually managed to do something like this once, though not with TJDO.)
4) somehow something has intervened and deleted the probe table between creation and test ( .001 percent chance)
I'm guessing that the DELETE_ME*** table is being left behind in the database, but if not, you could manually create a table with that name. Then you could throw together a quick-and-dirty test that would validate that it's one of the first two problems (and be available to test alternate drivers/DBs).
We (TJDO) really ought to have a driver validator for diagnosing problems like this, it ought to be pretty simple. I'll see if I can start one this weekend, but I'm not promising...