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