I took an hour this morning and made an attempt to hack the relational metamodel, but it failed.
Would the Materialized Physical table be just an "EReference of somekind? Seems like it since it'll be "external" to the virtual model.
You've hacked before JPAV.... what would it take? :)
The solution I have locally now would just have to tweak the get/set methods on the virtual table.
Barry
----- Original Message -----
From: "John Verhaeg" <jverhaeg@redhat.com>
To: "Barry Lafond" <blafond@redhat.com>
Cc: "John Doyle" <jdoyle@redhat.com>, "teiid-designer-dev" <teiid-designer-dev@lists.jboss.org>, "teiid-dev" <teiid-dev@lists.jboss.org>
Sent: Tuesday, July 13, 2010 12:05:48 PM GMT -06:00 US/Canada Central
Subject: Re: [teiid-designer-dev] Materialized Views
On Jul 13, 2010, at 10:04 AM, Barry Lafond wrote:
JPAV, do our validation rules have to be implemented via EMF? and/or can they be applied to a simple IResource (i.e. xxxx.vdb file)?
No, they can be applied to either.
> That all said, would it be wrong to NOT treat these Materialization Physical models as dependencies? Users would be totally responsible for including them in a VDB containing the original virtual models?
I think it would be wrong, yes. I understand it's a bit more work to modify our metamodels to handle this, but I'd say we need to.
While it certainly would be best to add them automatically like we do for other models, would it be possibly to flag a missing Materialization Physical model as a validation error on a VDB without changing the metamodel? Would that be good enough?
It's possible, but as Barry pointed out, it's not very practical. The VDB framework doesn't deal with EMF at all, and to determine that a materialization model is referenced, we'd need to parse the model. That would also mean every model would be parsed twice, once by the normal build process and again by the VDB validation process.