You are viewing a plain text version of this content. The canonical link for it is here.
Posted to ojb-user@db.apache.org by Charles Anthony <ch...@hpdsoftware.com> on 2004/09/28 08:25:44 UTC
RE: Problem: Changing a ClassDescriptor's table at runtime - help
!
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:jason@jCraftsmen.com]
> 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: ojb-user-unsubscribe@db.apache.org
> For additional commands, e-mail: ojb-user-help@db.apache.org
>
>
___________________________________________________________
HPD Software Ltd. - Helping Business Finance Business
Email terms and conditions: www.hpdsoftware.com/disclaimer
---------------------------------------------------------------------
To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-user-help@db.apache.org
Re: Problem: Changing a ClassDescriptor's table at runtime - help
!
Posted by Armin Waibel <ar...@apache.org>.
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:jason@jCraftsmen.com]
>>> 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: ojb-user-unsubscribe@db.apache.org
>>> For additional commands, e-mail: ojb-user-help@db.apache.org
>>>
>>>
>>>
>>
>>
>>
>> ___________________________________________________________
>> HPD Software Ltd. - Helping Business Finance Business
>> Email terms and conditions: www.hpdsoftware.com/disclaimer
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
>> For additional commands, e-mail: ojb-user-help@db.apache.org
>>
>>
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
> For additional commands, e-mail: ojb-user-help@db.apache.org
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-user-help@db.apache.org
Re: Problem: Changing a ClassDescriptor's table at runtime - help
!
Posted by Jason Mihalick <ja...@jCraftsmen.com>.
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:jason@jCraftsmen.com]
>>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: ojb-user-unsubscribe@db.apache.org
>>For additional commands, e-mail: ojb-user-help@db.apache.org
>>
>>
>>
>>
>
>
>___________________________________________________________
>HPD Software Ltd. - Helping Business Finance Business
>Email terms and conditions: www.hpdsoftware.com/disclaimer
>
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
>For additional commands, e-mail: ojb-user-help@db.apache.org
>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-user-help@db.apache.org