[teiid-designer-dev] Potential Designer Source Bindings Strategy

[John Doyle]

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 at 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 at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/teiid-designer-dev