This is a book, not an email -:)
I gathered two main points here
1) You want to only create Connection Factories (CF) for the physical
models you define. No more than that.
2) You only want to keep the "logical" name of the CF along with the
Model, and match up when the default Teiid comes to scope. if no matches
you let them pick existing or create a new one.
Few more inline comments below. Can you show any mockups perhaps?
On Thu, 2010-04-08 at 12:03 -0500, John Verhaeg wrote:
First, keep in mind Teiid has modified the configuration format and
content within a VDB such that no connector or connection factory
definitions (what we previously called connector types/component types
and connector/connector bindings, respectively) are stored within the
VDB. That means things like the URL and user name of the sources to
which physical models will connect are not carried forward within the
VDB.
This is a choice we have. If we want we can still have this inside VDB,
as default CF. That just needs to be in any "???-ds.xml" file. A sample
of this you can find with SteveH provided migration tool.
In addition, the ability to create new connectors (again, what we
used
to call connector/component types) from the Designer will no longer be
supported; that ability will be provided instead via new connector
development tooling (a CDK replacement).
This is never true. Designer provided a
way to *import* a Connector. Not
create a new one. It should be no different now to support the custom
connectors.
The only connection-related information that will remain is a
binding
from each model in the VDB to a "logical" connection name that can be
mapped to any real connection factory by an administrator when the VDB
is actually deployed. The idea here is to transform VDBs into more
portable artifacts that can be moved from one environment to another
without modification.
Yes, this should be the intended behavior.
In the development environment, we still want the modeler to have a
"sandbox" or "default" Teiid available to do things like previewing
data and testing VDB deployment/querying; this is inline with
functionality available in previous MetaMatrix Designer products that
was available via an embedded Teiid. To ensure the user experience
for the modeler remains as straight-forward as possible, we'll be
automating a few things, for instance, ensuring that preview remains
pretty much a one-click operation and attempting to automatically map
models to connectors on the default Teiid (using information when
available for imported physical models) to remove the modeler's
concern for the aforementioned logical connection name.
In last sentence above
scratch "connectors" with CF, then it makes
sense.
We are planning to have a Teiid view within the Designer that replaces
the previous Connector, Connector Binding, and Source Binding views (I
might have some of the old names wrong here), and that allows a user
to:
* See which Teiid instances are currently configured and
available for use regarding VDB deployment, preview, and
binding between models and connectors (via connection
factories). Note, the first Teiid configured will act as the
"default" in this regard, but we will still allow the user to
pick a different Teiid to act as the default. Also note, in
the case of "bundled" offerings such as the JBDS product, a
Teiid instance will be automatically configured and set as the
default without any user interaction.
* See which connectors, connection factories, and VDBs are
currently deployed on each Teiid instance, using any of those
artifact types as focal points to categorize the view.
* "Go into" or "pivot" the view to focus on particular types
of
entities shown within this view, such as drilling into a
particular connector to filter out all information expect
which connection factories and VDBs/models are tied to that
connector, or pivoting the view such that the VDBs are the
top-level entry in the tree.
Please note that a CF is a connection to a source of type "Connector".
So, a "Connector" is kind of an attribute to the connection. I would not
put too much emphasis on "Connector" to show up in views, grouping or
otherwise. IMO, "vdb" has "CF" is good enough info.
What we've been discussing NOT providing in this view, which I believe
is primarily the point Barry was bringing to light in his initial
post, is the ability to create connection factories arbitrarily
without being tied initially to a particular model (or models). The
creation of connection factories will now be a task performed by the
user within the context of building a VDB. The motivation behind not
managing connection factories and their properties from this view has
nothing to do with not having an embedded Teiid available, but rather
is driven by the realization that connection and "binding" management
is always intrinsically tied to the particular models that will be
deployed within VDBs, and that changes to connection factory
properties do not get persisted within the VDB and therefore only
apply to the local environment. We are instead relying upon JOPR/JON
for this type of management, which is always available via a browser
for any configured Teiid instance, and may even end up as another
plug-in within JBT/JBDS. In other words, we're saying management of
particular properties for a connection (especially anything beyond the
standard URL, user name, and password) are concerns for a Teiid
administrator, and not a modeler.
For every physical model added to a VDB, we will attempt to
automatically create a connection factory that ties the model to an
appropriate connector on the default Teiid using import information.
If a match cannot be determined or import information doesn't exist
(such as for manually created models), the user will be required to
select a connector from the default Teiid and enter required
connection properties (URL, user name, password) from within the VDB
editor, at which point a connection factory will be automatically
created on the default Teiid. All of this remains very similar to the
user experience in previous MetaMatrix Designer versions. Management
of connection factories will be completely automated, such that when a
model is deleted from both all VDBs and the workspace, its
corresponding connector factory on the default Teiid will also be
deleted.
I am not sure how you would draw the line which properties are important
for the modeler vs admin. However this is more or less same behavior we
had in the JDBC auto creation of the "connector binding". I do like the
selection of already existing or possibly create a new one. However,
this puts right back to where we started as per the creation of the CF,
with difference that, Designer will not have *view* to show or create
ad-hoc CFs. Which I think is fine.
The one issue I see if for some reason user likes to switch model's
binding from CF-A to CF-B it may be tricky?
I also, would recommend to provide in the above mentioned "pivot" view a
way "export" CF for given VDB. So, that they can take with them to other
environments as a template.
Ramesh..