Installation requirements
by Paul Nittel
It's just a minor thing, but the downloads page (http://www.jboss.org/teiid/downloads.html) indicates you need Java 1.6 and Teiid Designer for an installation. I realize the Quick Start points out how it's installed in JBoss AS, but we might want to mention this on the Downloads page as well.
Cheers,
-------
Paul Nittel
JBoss Sr. Quality Assurance Engineer
Red Hat, Inc.
314-336-2907 (81-62907)
Delivering value year after year.
Red Hat ranks #1 in value among software vendors.
http://www.redhat.com/promo/vendor/
15 years, 10 months
VDB Data Policy structure
by Barry Lafond
Looking at vdb-deployer.xsd and the "data-policy" element....
I'm not sure how we inject table/column-specific permissions from Designer?
The "permission" complex type contains CRUD values for a "resource-name" element. Is this element supposed to be used for a named object within a model like the table: PartsOracle.PARTS.SUPPLIER?
I created a sample xml fragment below. Can you comment?
<data-policy name="HR Model Data Policy">
<description>Access to HR department to create, read, update and delete personnel records.</description>
<permission>
<resource-name> HROracleAllView </resource-name>
<allow-create>TRUE</allow-create>
<allow-read>TRUE</allow-read>
<allow-update>TRUE</allow-update>
<allow-delete>TRUE</allow-delete>
</permission>
<permission>
<resource-name> HROracleAllView.Management.Payrol l </resource-name>
<allow-create>FALSE</allow-create>
<allow-read>TRUE</allow-read>
<allow-update>FALSE</allow-update>
<allow-delete>FALSE</allow-delete>
</permission>
<permission>
<resource-name> HROracleAllView.Salary.Payroll </resource-name>
<allow-create>TRUE</allow-create>
<allow-read>TRUE</allow-read>
<allow-update>TRUE</allow-update>
<allow-delete>TRUE</allow-delete>
</permission>
<mapped-role-name>Full Personnel Records</mapped-role-name>
</data-policy>
<xs:element name="data-policy" minOccurs="0" maxOccurs="unbounded">
<xs:complexType>
<xs:sequence>
<xs:element name="description" type="xs:string" minOccurs="0"/>
<xs:element name="permission" minOccurs="1" maxOccurs="unbounded">
<xs:complexType>
<xs:sequence>
<xs:element name="resource-name" type="xs:string"/>
<xs:element name="allow-create" type="xs:boolean" minOccurs="0"/>
<xs:element name="allow-read" type="xs:boolean" minOccurs="0"/>
<xs:element name="allow-update" type="xs:boolean" minOccurs="0"/>
<xs:element name="allow-delete" type="xs:boolean" minOccurs="0"/>
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:element name="mapped-role-name" type="xs:string" minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:attribute name="name" type="xs:string" use="required"/>
</xs:complexType>
</xs:element>
Barry
15 years, 10 months
7.1 Alpha1 posted
by Steven Hawkins
Hello all,
7.1 Alpha1 is available. There are already quite a few features in there too -- http://teiid.blogspot.com/2010/07/71-pre-release.html
A couple of things to highlight, the Teiid rar files no longer have version numbers so that -ds.xml don't have to change between releases. Also you can get query plan information from any client tool with the show statement:
set showplan on
select ... from ...
show plan
The show plan statement will return a result set containing the plan text/xml/debug log.
See the release notes and updated docs in the kit for all the details.
Steve
15 years, 10 months
Teiid 7.1 alpha1
by Steven Hawkins
Hello all,
Any objection to releasing an alpha1 today?
Steve
15 years, 10 months
Teiid 7.1 alpha 1
by Steven Hawkins
Hello all,
It would be good to get an alpha release in the next day or two. Once TEIID-1149 and TEIID-1143 are addressed, I think we'll be ready to go. The next alpha release (~1 week) after that should contain some caching changes and our initial odbc support. We'll then proceed to beta and target a cr release on 8/3.
Steve
15 years, 10 months
Re: [teiid-dev] [teiid-designer-dev] Materialized Views
by Barry Lafond
I think that's a decent idea, however, our new VDB framework does not use EMF anymore, so our built-in "build" framework that utilizes "validation rules" may not work.
Currently we have no VDB-specific validation.
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)?
Barry
----- Original Message -----
From: "John Doyle" <jdoyle(a)redhat.com>
To: "Barry Lafond" <blafond(a)redhat.com>
Cc: "teiid-dev" <teiid-dev(a)lists.jboss.org>, "teiid-designer-dev" <teiid-designer-dev(a)lists.jboss.org>
Sent: Tuesday, July 13, 2010 9:43:22 AM GMT -06:00 US/Canada Central
Subject: Re: [teiid-designer-dev] Materialized Views
----- "Barry Lafond" <blafond(a)redhat.com> wrote:
>
> All,
>
......
> 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?
>
> Comments, ideas?
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?
>
> Barry
>
> _______________________________________________ teiid-designer-dev mailing list teiid-designer-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/teiid-designer-dev
15 years, 10 months
Materialized Views
by Barry Lafond
All,
Teiid Designer 7.1 is targeted to restore some notion of Materialized Views.
The MMX solution created the materialized tables within the VDB based on the "isMaterialized" property for each virtual table. The user had no other control of these "tables" during design-time.
For Teiid Designer, we chose to expose Materialization in a different way by allowing users to create Physical models representing the Materialized structure of virtual tables.
So the new use-case is:
1) User selects one or more "virtual" tables in a virtual model
2) Right-click select "Modeling > Create Materialized Views" action
3) Selecting existing physical model (or schema within that model) or Create new physical relational model.
4) Each "virtual table" has it's "isMaterialized" property set to TRUE and a "soft-reference" to the new "materialized" physical table is stored with the virtual table.
5) During build time, this "materializedView" reference UUID is set on the proper INDEX entry for the virtual table.
6) Since the "materialized" model is just a physical model, this model is indexed just like all other XMI files and if added to a VDB, its metadata is available just like any other model.
7) Note that in MMX, the Materialization model created in the VDB was a relational model with a "Materialization" model type, and not actually a Physical model. We're dropping the notion of a "Materialization" model type.
The scenario above, is basically coded and working.
The catch is that Designer's Relational and Transformation metamodels do not account for a "Materialized Table" reference on the virtual table EObject. For those of you who know about EMF, it can be a big deal to change our metamodel to accomodate this reference.
Without that metamodel change, Designer won't automatically detect the additional virtual model dependency, a new "model import" entry won't be created AND when adding the Virtual model to a VDB, the "Materialization" physical model won't automatically get added.
>From a Teiid standpoint, there would be more work required to complete the notion of what and how these Materialized physical models are used. This would probably included generating DDL for the purpose of creating new Schema on a DB to represent your MV's or something like that. (I'm still learning the ropes over here in "design-time-land)
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?
Comments, ideas?
Barry
15 years, 10 months
Designer VDB's and schema
by Barry Lafond
Steve, Ramesh,
Doyle ran into a deployment problem late yesterday and I logged TEIID-1145 to cover it. So far it's the only VDB that won't deploy that we've found in testing, but it's been sparse at best.
The question I have concerns the built-in datatypes schema model (.xsd) that we used to include in our VDB's. Is that taken care of by Teiid now? We can still deploy a source model which uses built-in types and query it fine, so I'm assuming that's the case?
Barry
15 years, 10 months
New changes for the eclipse cdk plugin
by Sanjay Chaudhuri
I have uploaded fresh changes for the cdk plugin. The plugin now supports an
editor for the config-properties section of ra.xml. Changes made either on
config-properties editor or the raw xml view tab will be synchronized.
The ManagedConnectionFactory.java doesn't yet get updated. I shall be
working on that next.
Thanks
Sanjay
15 years, 10 months
