9:55 a.m.
Quick question.
The current xsd for the vdb.xml file allows for PHYSICAL, FUNCTION, and VIRTUAL model
types.
What about the other legacy types (which were stored in the old manifest model)?
TYPE
VDB_ARCHIVE
UNKNOWN
CONFIGURATION
METAMODEL
EXTENSION
LOGICAL
MATERIALIZATION (a subtype of physical?)
Outside of matrerialization, the only information related to these models that was used at
runtime was the ConfigurationInfo.def model visibility entry to determine if the
corresponding .xmi file could be retrieved.
Steve
2:35 p.m.
On Mar 25, 2010, at 9:55 AM, Steven Hawkins wrote:
Quick question.
The current xsd for the vdb.xml file allows for PHYSICAL, FUNCTION, and VIRTUAL model
types.
What about the other legacy types (which were stored in the old manifest model)?
TYPE
VDB_ARCHIVE
UNKNOWN
CONFIGURATION
METAMODEL
EXTENSION
LOGICAL
MATERIALIZATION (a subtype of physical?)
Outside of matrerialization, the only information related to these models that was used
at runtime was the ConfigurationInfo.def model visibility entry to determine if the
corresponding .xmi file could be retrieved.
I don't yet know of any reason why we'd need the other types, especially some of
the weirder things like METAMODEL, UNKNOWN, or VDB_ARCHIVE. I'm pretty sure the
CONFIGURATION option doesn't apply anymore since we've combined it with the
manifest.
Thanks,
JPAV
2:46 p.m.
Just to restate from your and Barry's answers - the vdb.xml xsd should have allowable
model type values also for:
TYPE (.xsd)
EXTENSION
LOGICAL
MATERIALIZATION
----- 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 2:35:48 PM GMT -06:00 US/Canada Central
Subject: Re: [teiid-designer-dev] other model types
On Mar 25, 2010, at 9:55 AM, Steven Hawkins wrote:
Quick question.
The current xsd for the vdb.xml file allows for PHYSICAL, FUNCTION, and VIRTUAL model
types.
What about the other legacy types (which were stored in the old manifest model)?
TYPE
VDB_ARCHIVE
UNKNOWN
CONFIGURATION
METAMODEL
EXTENSION
LOGICAL
MATERIALIZATION (a subtype of physical?)
Outside of matrerialization, the only information related to these models that was used
at runtime was the ConfigurationInfo.def model visibility entry to determine if the
corresponding .xmi file could be retrieved.
I don't yet know of any reason why we'd need the other types, especially some of
the weirder things like METAMODEL, UNKNOWN, or VDB_ARCHIVE. I'm pretty sure the
CONFIGURATION option doesn't apply anymore since we've combined it with the
manifest.
Thanks,
JPAV
3:11 p.m.
On Mar 25, 2010, at 2:46 PM, Steven Hawkins wrote:
Just to restate from your and Barry's answers - the vdb.xml xsd
should have allowable model type values also for:
TYPE (.xsd)
EXTENSION
LOGICAL
MATERIALIZATION
I'm confused. I thought you were saying the runtime doesn't care about these
distinctions because it only cares about the visibility entry. Is that not correct? I
thought I was agreeing with you that we probably don't need these extra types at all.
Also, I'm a bit confused about the visibility entry having to do with the XMI file
being retrieved. I thought that flag determined whether the model was visible via JDBC.
When and why does the runtime need to retrieve the model?
Thanks,
JPAV
3:33 p.m.
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?
----- 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 3:11:31 PM GMT -06:00 US/Canada Central
Subject: Re: [teiid-designer-dev] other model types
On Mar 25, 2010, at 2:46 PM, Steven Hawkins wrote:
Just to restate from your and Barry's answers - the vdb.xml xsd
should have allowable model type values also for:
TYPE (.xsd)
EXTENSION
LOGICAL
MATERIALIZATION
I'm confused. I thought you were saying the runtime doesn't care about these
distinctions because it only cares about the visibility entry. Is that not correct? I
thought I was agreeing with you that we probably don't need these extra types at all.
Also, I'm a bit confused about the visibility entry having to do with the XMI file
being retrieved. I thought that flag determined whether the model was visible via JDBC.
When and why does the runtime need to retrieve the model?
Thanks,
JPAV
4:22 p.m.
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
5166
days inactive
5166
days old
teiid-designer-dev@lists.jboss.org
5 comments
2 participants
participants (2)
-
John Verhaeg -
Steven Hawkins