BTW, given that I as a user can check to see if a table already exists, maybe the CREATE TABLE code could do the same, rather than rely on a unique key violation?
On Mon, May 3, 2010 at 2:25 PM, Mike Matrigali <[email protected]>wrote: > what are the names of the new files after the transaction that > tried to create the existing table them commits? If they are still c*.dat > then there > is definitely something wrong. If they start with a different letter > then it could be that derby is acting as expected and just did not get > around to cleaning them > yet. I believe it does this at checkpoint time. The assumption being > that normally this case is just drop table and not needed to be optimized. > > I have not looked at the code but my guess is that create table is > counting on a unique key violation to tell whether a table exists > or not. To do this it has to do an insert and to do the insert it > needs the name of the file which only exists after the file is > created. > > David Van Couvering wrote: > >> Yes, it does sound like a bug. I'll log a JIRA >> >> On Fri, Apr 30, 2010 at 6:50 PM, Bryan Pendleton < >> [email protected] <mailto:[email protected]>> wrote: >> >> As I mentioned to Knut, I try to issue a CREATE TABLE each time >> I connect, and ignore the exception saying it already exists if >> the table is already there. >> >> If this is leaking a conglomerate each time (creating a .dat file but >> never deleting it), that seems like a bug to me. >> >> thanks, >> >> bryan >> >> >> >> >> -- >> David W. Van Couvering >> >> http://www.linkedin.com/in/davidvc >> http://davidvancouvering.blogspot.com >> http://twitter.com/dcouvering >> > > -- David W. Van Couvering http://www.linkedin.com/in/davidvc http://davidvancouvering.blogspot.com http://twitter.com/dcouvering
