Hi, Yes, I can confirm the StatementsForClassImpl does cache the generated SQL for each class, and the ClassDescriptor keeps hold of the StatementsForClassIF.
I would agree that your best way forward would be to implement a new StatementsForClassIF. (I would suggest subclassing the existing StatementsForClassImpl, and simply providing a method to set the deleteSql, insertSql,updateSql and selectByPKSql attributes to null. Unfortunately, the attributes are private, so I think it's time for a bit of cut-n-paste re-use) Cheers, Charles. > -----Original Message----- > From: Jason Mihalick [mailto:[EMAIL PROTECTED] > Sent: 28 September 2004 02:15 > To: OJB Users List > Cc: Armin Waibel > Subject: Problem: Changing a ClassDescriptor's table at > runtime - help! > > > All, > > Since around OJB 1.0 RC 4, we have had some code that toggles > the table > that a ClassDescriptor is pointing to at runtime using the > ClassDescriptor.setTableName(). The tables that we switch > between have > identical structure. As long as we took care of sequence manager > issues, cleared the object cache, and released all broker instances, > life seemed to be good. We could easily store objects of a > single class > into different tables at runtime ... SLICK! > > Recently, though, when running some tests, I have found that > switching > the targeted table isn't working. One major difference in our > application is that we have upgraded to OJB 1.0. I've done some > debugging and found that now, for example, if I run any > operations that > cause an insert AND THEN switch the tablename and attempt another > insert, I have problems. The problem is that OJB still wants > to insert > data into the original table that was configured before I > switched the > tablename. I did some digging and noticed that there was a > good amount > of refactoring in ClassDescriptor and it *appears* that the > StatementsForClassImpl class is caching the SQL and causing > the original > SQL to be executed even after I change the tablename. > > So here is the question: To anyone that knows the ClassDescriptor > implementation and understands how OJB 1.0 caches statements > and the SQL > for them, does this new problem seem consistent with OJB 1.0's > implementation? If so, do you have any ideas on how I can > work around > it?. I am contemplating writing my own version of > StatementsForClassImpl that allows me to clear the cached SQL, but I > want to make sure my diagnosis of the problem is correct before I go > down that path. > > Any help is much appreciated. > > -- > Jason > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > ___________________________________________________________ HPD Software Ltd. - Helping Business Finance Business Email terms and conditions: www.hpdsoftware.com/disclaimer --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
