Mailing-List: contact dev-help@continuum.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@continuum.apache.org
Received-SPF: neutral (athena.apache.org: local policy)
Message-Id: <A0B84BC1-3CDB-4274-9499-54F23CAE7F01@apache.org>
From: Brett Porter <brett@apache.org>
To: dev@continuum.apache.org
In-Reply-To: <dc05e5f20811180519y323dbb3g6d41a52f17e08da1@mail.gmail.com>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v929.2)
Subject: Re: Database compatibility checking step during startup
Date: Wed, 19 Nov 2008 15:28:03 +1100
References: <dc05e5f20811180519y323dbb3g6d41a52f17e08da1@mail.gmail.com>

There's actually a version tracked in the modello metadata database  
table for this purpose already.

The tricky part is how to do the conversion - that seems to need to be  
done outside of modello because of the complexity of having multiple  
versions (see what it did to the data management :) I think if you  
init normally, but don't load any data, then check that table for the  
right version, you can decide to upgrade it before loading any data.  
You'll need to lock the store accesses while that occurs. I expect  
we'd use some other migration tool like has been discussed recently  
for the task.

- Brett

On 19/11/2008, at 12:19 AM, Napoleon Esmundo C. Ramirez wrote:

> Hello everyone,
>
> Deng and I talked about putting a database compatibility check.  I  
> filed
> CONTINUUM-1980 to track this new feature.  In summary, it states that
> Continuum should be able to detect when it has been started with an
> incompatible database and prompt the user to take the appropriate  
> action.
> This should work transparently if all goes well, and will just display
> recommendations in the UI if any problem occurred.
>
> By intent, the checking should take place before the database  
> connection is
> initialized.  But since the database connection happens during the
> components' initialization, it is suggested that the JdoFactory for  
> the
> continuum database be removed in the application.xml and is instead  
> replaced
> with a wrapper component that initializes the database connection
> explicitly--not on component initialization.  This new component can  
> be used
> by a database-checking interceptor in the webapp or it can be  
> applied to
> other modules like the redback users database.
>
> For now, aside from the new interceptor and component suggested to  
> be added
> to continuum, the impact I can see is that the following will have  
> to point
> to the new component:
> - org.apache.maven.continuum.management.StoreUtilities
> - org.apache.maven.continuum.management.JdoDataManagementTool
> - org.apache.maven.continuum.management.LegacyJdoDataManagementTool
>
> Currently, they require the the continuum JdoFactory:
> /**
> * @plexus.requirement role="org.codehaus.plexus.jdo.JdoFactory"
> role-hint="continuum"
> */
>
> But I think these components don't need the JdoFactory right away,  
> so I
> think we can delay the initialization of the database connection  
> component
> to give way to checking during startup.
>
>
> What do you think?  Any comments are greatly appreciated.
>
> Cheers!
> Nap

--
Brett Porter
brett@apache.org
http://blogs.exist.com/bporter/