Yip,
My guess is that startWriting clears all the data dictionary caches so that individual sql statement implementations don't have to worry about dealing with keeping the cache clean. Because if a statement missed cleaning the cache (like it happened for ALTER TABLE ADD COLUMN) then we could end up with bugs like DERBY-1847. So, I guess for code maintainability, Derby might have chosen to cleanup all the caches. I don't know why this logic is not applied to permission cache though. startWriting() does not cleanup the permission cache and looks like it is expected to be done by the inidividual sql statements whereever necessary.
But like I said, this is just a theory I deducted from the current implementation. Someone else might have more concrete answer.
Mamta
On 9/25/06, Yip Ng <[EMAIL PROTECTED]> wrote:
Hi
I am looking through the data dictionary code and I am wondering why the system needs to clear *ALL* the data dictionary caches (table descriptors, etc.) at startWriting(), what is the reason behind this? Wouldn't clearing just the "affected" descriptor(s) in the DDL's constant action enough?
Yip
