6:45 a.m.
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(a)redhat.com>
To: "John Verhaeg" <jverhaeg(a)redhat.com>
Cc: "teiid-designer-dev" <teiid-designer-dev(a)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(a)redhat.com>
To: "Steven Hawkins" <shawkins(a)redhat.com>
Cc: "teiid-designer-dev" <teiid-designer-dev(a)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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/teiid-designer-dev
9:51 a.m.
New subject: other model types
On Mar 26, 2010, at 6:45 AM, Barry Lafond wrote:
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?
I'm curious about this, too. Doesn't the Teiid need to distinguish type models
from physical and virtual models?
From: "Steven Hawkins" <shawkins(a)redhat.com>
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.
I really think we ought to treat this file and especially its schema as being
"owned" by and "for" Teiid, not the Designer. So I feel the
enumeration for this attribute should just contain the values Teiid needs, and any
remaining concerns on the Designer side can be handled via properties.
Thanks,
JPAV
5402
days inactive
5402
days old
teiid-designer-dev@lists.jboss.org
1 comments
2 participants
participants (2)
-
Barry Lafond -
John Verhaeg