[teiid-designer-dev] Preview VDB Cleanup

John Verhaeg jverhaeg at redhat.com
Fri Jan 28 10:44:56 EST 2011


If I understand correctly, the whole reason we deviated from this initial design was due to a JIRA logged by Ramesh predicated on the idea that there'd be some way for the local PVDBs to get out-of-sync with the server outside of the Designer.  I'd like to hear from Ramesh why he thought this was possible, because I can't figure out how that would happen in any reasonable manner, other than in some very rare edge-case.

On Jan 28, 2011, at 9:33 AM, John Verhaeg wrote:

> On Jan 28, 2011, at 8:07 AM, John Doyle wrote:
> 
>> I vote for 1 also, but I think that 3 is not a good option.   Just like the timer we're making a decision for the user that they may not like.  Sure, the user can clean them up individually if they like, but that's onerous and someone will immediately complain.
> 
> Correct me if I'm wrong, Barry, but I think what he's referring to involves not just removing cleanup, rather the whole idea of ever cleaning anything up unless a model is deleted (or by an admin action via the JON/RHQ).  
> 
> This was our initial approach when designing all of this.  Given where you're at now, of course, that whole plan would be something you'd have to do in 7.4 or later.  But the idea behind this approach does not involve the user individually cleaning up anything.  It would require the ability to compare a timestamp or something similar between the local PVDB and the one deployed on the server (which Teiid doesn't provide currently), and would mean lots of PVDBs would remain on the server, therefore calling for some way to automatically filter their presence from JON/RHQ/Designer when viewing deployed VDBs (unless a non-persisted flag is turned on).  This also is something we discussed in the past.  
> 
> The advantages behind this approach are 1) we no longer need to worry about multiple timeframes in our tooling where we need to do cleanup (i.e., startup or shutdown), which is fairly time consuming, involves non-trivial code, and leaves the user/Designer in an awkward situation if the server isn't available at those times, and 2) Designer would re-use PVDBs from previous sessions, again saving lots of time and allowing the user to choose another server if the current one is down without having to regenerate all of the local PVDBs.


JPAV




-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/teiid-designer-dev/attachments/20110128/082fb170/attachment.html 


More information about the teiid-designer-dev mailing list