[
https://issues.jboss.org/browse/TEIIDDES-905?page=com.atlassian.jira.plug...
]
Barry LaFond commented on TEIIDDES-905:
---------------------------------------
Good conversation about overlapping MED's (M Drilling and B LaFond)
(01:45:23 PM) mdrilling: I'm looking at
https://issues.jboss.org/browse/TEIIDDES-1051
(01:45:28 PM) blafond: sure
(01:45:34 PM) blafond: I logged that one, right?
(01:45:58 PM) mdrilling: yep. Running SF importer to merge SF tables into an existing
Relational Model
(01:46:47 PM) mdrilling: Seems like even allowing to do that is bad. I'm thinking we
should look at the model to see if it already has SF in it. If no, disallow
(01:47:07 PM) mdrilling: you cant mix non-SF with SF tables in a model right?
(01:47:26 PM) blafond: A SF table is exactly the same as any other relational table
(01:47:46 PM) blafond: only the "<annotations> & <tags> will be
added
(01:48:41 PM) blafond: I would say that checking for a SF MED is good. No need to
write-over a built-in MED.
(01:48:57 PM) mdrilling: but if you merge a table with the annotations/tags into a
relational model, then every other table will pick up those properties
(01:49:11 PM) blafond: When the Tables get created, though, any non-default SF Extension
props need to get set on the tables
(01:49:35 PM) blafond: Not from an XMI standpoint
(01:49:55 PM) mdrilling: when which tables get created?
(01:49:59 PM) blafond: At Indexing time, all tables will get at least the DEFAULT MED
properties
(01:50:48 PM) mdrilling: will every relational model have the SF meds?
(01:51:14 PM) blafond: no. Only the modes that have been "imported into or created
by" the SF importer
(01:51:35 PM) blafond: Right now there is no Direct way to apply an MED to a relational
model
(01:52:04 PM) blafond: Remember that only the SF translator will even care about these
props
(01:52:28 PM) blafond: JDBC wouldn't know to look for them, for instance
(01:56:31 PM) blafond: In the OLD model extension framework, no DEFAULT values were stored
in the actual extended metamodel (i.e. mySalesforce.xmi)
(01:57:04 PM) mdrilling: but does it even make sense to mix? Say I have model imported
from jdbc. Seems bad to allow import of SF into it. How would I query the tables / what
translator would be used?
(01:57:06 PM) blafond: At Indexing time, RuntimeAdapter looked back at the actual
SalesforceExtensions.xmi to get the default values
(01:57:47 PM) blafond: In 7.6 we'll address these issues with validation and an MED
management UI framework
(01:58:03 PM) blafond: in 7.5, it's OK to allow them to apply it.
(01:58:19 PM) blafond: If user 1) Imports PartsSupplier
(01:58:36 PM) blafond: 2) Imports from SF and adds some SF Tables to PartsSupplier
(01:58:52 PM) blafond: 3) Adds PS to a VDB and set's the Translator to Salesforce
(01:59:00 PM) blafond: 4) Deploys and queries the SF tables....
(01:59:06 PM) blafond: They'll get SF data back
(01:59:42 PM) blafond: The JDBC tables, would be useless unless they just happen to match
up with SF table
(02:00:01 PM) mdrilling: what if they query PartsSupplier tables. invalid translator
error?
(02:00:40 PM) blafond: no, if the translator is SF, it'd be a "Table_A not
found" or something like that
(02:00:59 PM) mdrilling: ok
(02:01:03 PM) blafond: You could deploy that SAME VDB with a JDBC translator and then be
able to query PartsSupplier, but not the SF tables
(02:01:18 PM) blafond: Indexed VDB Metadata is just that. Indexed metadata. Until it's
queried, there is no resolving, etc..
(02:05:18 PM) blafond: If you look at what TAGS really are (name value string pairs) there
is NO WAY Teiid Server can determine what an extension property is supposed to be used
for. Not enough "metadata" on the index row. They just expose the metadata to
any translator that wants to look for something "Extra"
(02:06:20 PM) mdrilling: yeah
(02:06:48 PM) blafond: It's really a "simple" concept from a
"Teiid" perspective.
(02:07:20 PM) blafond: Making it work generically and makeing it useful for the UI/MOdeler
that's much more difficult to describe and implement
(02:11:16 PM) mdrilling: seems like potential confusion in the scenario above. After
importing SF into a JDBC model then all tables will look the same (the old jdbc tables
will have all the SF properties displayed)
(02:12:31 PM) blafond: yes
(02:13:04 PM) blafond: in 7.6 there be warnings BEFORE a user mixes MED's or adds SF
to a JDBC imported model
(02:13:19 PM) mdrilling: k
(02:13:58 PM) blafond: SF usage is probably < 10% maybe even 5%, so doubt this will be
an issue with more than maybe 1 brave sole over the next couple of months
Replace EMF-based Model Extensions with new framework
-----------------------------------------------------
Key: TEIIDDES-905
URL:
https://issues.jboss.org/browse/TEIIDDES-905
Project: Teiid Designer
Issue Type: Enhancement
Affects Versions: 7.3
Reporter: Barry LaFond
Assignee: Dan Florian
Priority: Critical
Fix For: 7.6
Designer's current Model Extensions framework has some limitations which include:
1. The current framework allows for only 1 extension model.
2. Extension models are included as a dependent models in VDBs.
3. When sequenced through publishing into the Modeshape repository none of the default
"extended" property values are currently sequenced. There is no mechanism in
Modeshape to associate 2 or more documents in this way.
4. When using the EMF Extension Model, EMF controls when Annotation objects are
created, and we're creating annotation objects even when none are strictly needed
(e.g., all the tags in the annotation have default values, and thus don't appear in
the XMI file). The result is a lot of unnecessary Annotation objects.
Need to design a new framework that is scalable, allows for applying multiple extensions,
includes the extension metadata within a model (initial values and types) and can be
easily adapted/sequenced by Modeshape.
--
This message is automatically generated by JIRA.
For more information on JIRA, see:
http://www.atlassian.com/software/jira