Hi Jason,
if you use a single threaded application then your solution is fine. Changing the table name of a ClassDescriptor is a global change, all threads will be aware of the changes, because the metadata classes are shared.
If you miss a method (refresh() or clear()) on StatementsForClassIF, please make a feature request for OJB1.1 on dev-list or scarab. Shouldn't be a problem to add such a method.
regards, Armin
Jason Mihalick wrote:
Thanks for the confirmation, Charles. I implemented a custom StatementsForClassImpl as described below in addition to making sure that I cleared the sequence name attribute on the FieldDescriptor of the primary key for the class. Works like a charm!
I would consider contributing this implementation, but I think there should be a better way to do this. One disadvantage to this implementation is that you must have this special implementation of the StatementsForClassIF in place in order to make this work. It seems to me like this should just be a feature that should just work "out of the box" -- regardless of your StatementsForClass implementation.
-- Jason
Charles Anthony wrote:
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]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
