Just an initial thought with only one read through. Would it be a good idea to implement
"entire redeploy' strategy described in the last paragraph to see if there is a
performance issue?
~jd
----- "Daniel Florian" <dflorian(a)redhat.com> wrote:
I want to outline a strategy for using the Teiid server to manage
the
Designer's Eclipse workspace source bindings (model to connector
mappings). These source bindings are used when a user previews data in
the Designer. Some of us have talked about this in the past but I
wanted to get it out there for all to see and comment on. Let me know
what you think.
Here's the strategy:
For each Teiid server registered within the Designer, an associated
VDB will be created. These VDBs will be hidden from the user and will
not appear in their Eclipse workspace. These VDBs will be deployed
(unbeknownst to the user) to their associated Teiid server and will
contain all the models from the workspace that have source bindings
with connectors installed on that server. These local, hidden VDBs and
their associated deployed VDB must stay in sync. The class in charge
of this will be the SourceBindingsManager (SBM).
Here are some use cases:
Designer Startup Use Case - same as Server Refresh Use Case. When the
Designer is started each server found in the persisted server registry
is refreshed.
Server Refresh Use Case- when a Teiid server is refreshed within
Designer, the SBM for that server will also be refreshed. The SBM's
cache of SourceBindings is cleared and re-populated based on
information gathered after obtaining the deployed, hidden VDB from
each server.
- delete all existing hidden, local VDBs
- for each registered Teiid server:
-- create a hidden, local VDB
-- if the hidden VDB is *not* deployed on the server no action is
taken by the SBM
-- if the hidden VDB is deployed on the server the SBM will:
--- for each model in the deployed VDB:
---- if model does *not* exist in workspace remove model from
deployed VDB unless path equals a closed project path
---- if model does exist in workspace:
----- if model does *not* have a connector remove it from deployed
VDB (see Issues below)
----- if model does have one or more connectors add model to local
VDB and create a SourceBinding with the connectors
--- if deployed VDB has no models delete it from server (see Issues
below)
Design Time Use Cases (hidden VDB already exists)
A source binding is created:
- ensure model exists in hidden VDB
- if model already has a SourceBinding remove from hidden VDB
- add SourceBinding to hidden VDB
- using Admin API add connector to model of deployed VDB (or redeploy
entire VDB, see Issues below)
A source binding is removed:
- if the model does *not* exist in the VDB throw Exception (not sure
this will happen, maybe an assertion)
- remove model from hidden VDB
- remove model from deployed VDB (or redeploy entire VDB, see Issues
below)
A project is opened:
- follow Server Refresh instructions for each model in the project
A project is closed:
- for each model in project, follow remove source binding
instructions except don't do anything to deployed VDB. These
connectors need to stay in the deployed VDB for when the project is
opened.
A project is deleted:
- for each model in project follow instructions for removing a source
binding except only redeploy done removing all models
A model is deleted:
-- if a source binding exists on this server then follow instructions
for removing a source binding
Designer Shutdown Use Case
- SBM has nothing to do
Issues
- Can we have a deployed VDB on Teiid that doesn't have any models
(maybe marked inactive)? If yes, we can create the VDB when we create
the associated Teiid server object. Then the deployed VDB lifecycle
would be the same as the Designer's Teiid server object. Trick would
be to make sure this deployed VDB exists the first time the connection
is established. Remember servers can be created without connecting to
them.
- Can you query a model with a connector that is in a VDB that has
another model which doesn't have a connector? If yes, we can
add/remove models to the hidden VDB as models are created/removed in
the workspace.
- It would be much simpler for us to manage the local VDB and redeploy
it in its entirety each time a change is made but their might be
performance issues associated with that. But this might be the only
way to get the indexes updated.
_______________________________________________
teiid-designer-dev mailing list
teiid-designer-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/teiid-designer-dev