[teiid-designer-dev] other model types

[Steven Hawkins]

Now we have:

Barry - include them all

and

John - include them only if there is some ui reason

So they should be included then, because Designer is a ui and used to use those values for something?  

Just to make sure my assumptions are correct, if there is additional values you guys want to track, then they will be set as properties on the model in the vdb.xml rather than going into a separate model manifest (such as the old entries for model, path, uuid, or update time)?  And if that is the case then it seems like you will want model entries in the vdb.xml for these other model types.

----- Original Message -----
From: "John Verhaeg" <jverhaeg at redhat.com>
To: "Steven Hawkins" <shawkins at redhat.com>
Cc: "teiid-designer-dev" <teiid-designer-dev at lists.jboss.org>
Sent: Thursday, March 25, 2010 4:22:53 PM GMT -06:00 US/Canada Central
Subject: Re: [teiid-designer-dev] other model types

On Mar 25, 2010, at 3:33 PM, Steven Hawkins wrote:

> We need to separate a couple of things out here.
> 
> My current understanding is that the vdb.xml file is becoming a replacement for both the ConfigurationInfo.def file and MetaMatrix-VdbManifestModel.xmi.  The old ConfigurationInfo file did not contain any model type information - that was in the VdbManifestModel.  The proposed schema for vdb.xml does contain model type - but only allows PHYSICAL, VIRTUAL, and FUNCTION.
> 
> Runtime uses this information in the following ways:
> 1. model type - available of our managed ModelMetadata, which
>   a. drives UI - such as show physical models in a display relating to connector bindings.
>   b. (Teiid 7.0 new) allows us to determine function models so that they can be loaded into the query metadata.
> 2. the model entry in the old ConfigurationInfo.def and in the new vdb.xml contains visibility information which we use to
>   a. hide virtual or physical metadata from users.
>   b. determine whether the actual model resource is retrievable through system procedures.  This is legacy behavior.  It does not seem like a very good idea to even allow this in general.  The only "models" that a client is really interested in retrieving are XSDs and that may no longer be needed given Ted's update of web service.
> 
> There are additional properties that we look at, but are specific to PHYSICAL models (dynamic vdb importer settings, multisource enablement, etc.).
> 
> So to re-rephase.  Designer previously used the MetaMatrix-VdbManifestModel.xmi to track models of types more than just PHYSICAL, VIRTUAL, and FUNCTION.  Does it still need/want to do that in the vdb.xml? 


Thanks for the clarification; that helps a lot.  I can't think of any reason to keep these other than some purely UI reason like wanting to show model-type-specific icons in a VDB editor or view.

Thanks,

JPAV