I don't think there is any "Designer" driver for keeping ALL model types except for John's point of decorating in VDB Editor, but it appears the provider for that table uses a "File" or ModelResource to get the image. It does not use the xml modelType data. So I'd say go with the short list.
But, to play devil's advocate.... if we have a FUNCTION or TYPE model, what do we put as the ModelType in the xml? I guess not add the attribute for those models?
Barry
----- Original Message -----
From: "Steven Hawkins" <shawkins@redhat.com>
To: "John Verhaeg" <jverhaeg@redhat.com>
Cc: "teiid-designer-dev" <teiid-designer-dev@lists.jboss.org>
Sent: Thursday, March 25, 2010 8:36:23 PM GMT -06:00 US/Canada Central
Subject: Re: [teiid-designer-dev] other model types
Just to clarify, model is an element under vdb and has a type attribute that allows for the enumerated values {PHYSICAL, VIRTUAL, FUNCTION}. Given the assumption that the new vdb.xml file replaces both the ConfigurationInfo.def and the MetaMatrix-VdbManifestModel.xmi, I am trying to ensure that the vdb.xml contains all the necessary information. So to have entries for all possible models (and there by a place holder for property elements), there needs to be an enumeration value for each model type.
On the other hand if you are saying Designer no longer has use for the information that was in MetaMatrix-VdbManifestModel.xmi, then Teiid does not need to have model entries for anything other than PHYSICAL, VIRTUAL, or FUNCTION model types.
----- Original Message -----
From: "John Verhaeg" <jverhaeg@redhat.com>
To: "Steven Hawkins" <shawkins@redhat.com>
Cc: "teiid-designer-dev" <teiid-designer-dev@lists.jboss.org>
Sent: Thursday, March 25, 2010 5:03:22 PM GMT -06:00 US/Canada Central
Subject: Re: [teiid-designer-dev] other model types
On Mar 25, 2010, at 5:00 PM, Steven Hawkins wrote:
> 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.
Yes, the property support is a good point. Unless Barry knows of a specific reason why the types are anything more than just a UI concern, it seems like we'd just use the generic property name-value pair support in the vdb.xml to support anything specific to the UI. Why would you guys support UI-only model types in the main schema if they're not useful in the runtime?
JPAV
_______________________________________________
teiid-designer-dev mailing list
teiid-designer-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/teiid-designer-dev