persistence@glassfish.java.net

Re: Have toplink code drop the tables from the database based on the old drop file

From: Rebecca Parks <June.Parks_at_Sun.COM>
Date: Thu, 17 Aug 2006 11:59:07 -0700

Is this relevant to Issue 919?

https://glassfish.dev.java.net/issues/show_bug.cgi?id=919

June

Pramod Gopinath wrote On 08/17/06 11:18,:

> Hi Tom
> A long time ago we had discussed this as part of introducing
> java2db support into the toplink code. At that point of time I had
> concentrated on introducing code into the glassfish framework to
> support this. Based on the current code base, I think we need to
> explore this option again. Below is a very rough proposal that I
> wanted to run by you. It would be great to hear your comments on this
> topic.
>
> _/Problem Description:/_
> As you are aware toplink drops the tables from the database based
> on the new entities that are part of the current application (pu in
> the case of EJB3.0). This is wrong because the entities could have
> changed and we should always try to drop the old objects (tables/FKs...)
>
> _/Proposed solution:/_
> The code in
> glassfish/entity-persistence/src/java/oracle/toplink/essentials/ejb/cmp3/EntityManagerFactoryProvider.java.generateDdlFiles()
> is aware of the drop files location and where we need to drop the
> entities. Based on the options then it calls
> createOrReplaceDefaultTables(). In there we could try to read the drop
> file and try to drop the entities. If this fails because the dropFile
> does not exist, then the code could continue to do what it does now
> (mgr.replaceDefaultTables(true)).
>
> _/Issues to be addressed:/_
> If we go down this path, need to do the following
> 1. read the drop file
> 2. get a hold of the connection (that is currently used to create the
> tables directly in the database if the user has selected the option)
> and use that option to execute the statements read as part of 1.
>
> Thanks
> Pramod