Teiid Designer 7.1 CR1 available
by Barry Lafond
Teiid Designer 7.1 CR1 release has been uploaded to sourceforge and it's available for download at: https://sourceforge.net/projects/teiid/files/ or via the link on our project downloads page.
This release contains Teiid 7.1 Final bits so be sure and upgrade your Teiid installation as well to 7.1 Final.
The Teiid Designer 7.1 Final release is planned for early next week. Our goal was to finish the planned set of features and we've essentially achieved that goal.
Looking ahead, there will be bug-fixing and tasks required during our 7.1.1 release to improve the behavior of some of these features and respond to user feedback.
Thx again to the team for working hard and coming a long way in a short period of time.
Happy Modeling
Teiid Designer Project Team
13 years, 11 months
Re: [teiid-dev] Teiid/Teiid Designer Security
by Steven Hawkins
>What is the current default - update-able nor not?
Should be updatable.
> Agreed. If data role checking is on by default in Teiid, some global
state in the VDB should indicate whether or not it is "participating" in
data role usage. Perhaps that global state is the presence of at least
one role. Perhaps it's a discrete setting. The challenge with only
checking roles if the VDB has them is that a user can assume the system
is locked down because role checking is on but a VDB with no roles
defined will be wide open.
You may be getting at something like an additional server setting "don't activate VDBs without roles". The problem is that you really can't protect VDB designers from themselves after a certain point. Just because a VDB has roles doesn't mean there isn't a default role that gives access to everything to everyone. I would be in favor of just enforcing roles if they are present. That also helps prevent more porting efforts with legacy VDBs if the default of the server is changed to check roles.
> Visibility is more than security. It's encapsulation. I don't think
users should use roles for that purpose - if that's what you're suggesting.
No I'm suggesting that visibility only applies to whether a table/model shows up in the system tables and has nothing to do with whether it can be accessed. To restrict accessibility, then roles would be used. This keeps the features distinct, but diminishes the visibility feature as encapsulation. It seems like the overlap of these features is where most of the security confusion came from. It seems that some assumed visible implied permissions.
I got tired of typing the last email, but would add that we could also consider SYS/pg_catalog as allow by default (instead of deny by default). Then system procedures would check their own authorizations against what is being targeted, e.g. refreshMatView may require an update permisison against the mat view. This would side step the question of whether the designer role permission editor should add controls for SYS/pg_catalog (TEIIDDES-568).
----- Original Message -----
From: "Ken Johnson" <kejohnso(a)redhat.com>
To: "Steven Hawkins" <shawkins(a)redhat.com>
Cc: "teiid-dev" <teiid-dev(a)lists.jboss.org>, "teiid-designer-dev" <teiid-designer-dev(a)lists.jboss.org>
Sent: Monday, August 23, 2010 9:03:39 AM GMT -06:00 US/Canada Central
Subject: Re: [teiid-dev] Teiid/Teiid Designer Security
On 08/21/2010 09:48 AM, Steven Hawkins wrote:
> Hell all,
>
> There is still a lot of confusion about security floating around. After another office conversation on Friday, it would be best to have an open discussion.
>
> First some perspective. MetaMatrix documentation described the securitizing process in layers (an expanded version of this will be added to the Teiid docs):
>
> 1. Be selective about what metadata is imported - only modeled items can be accessed. Most if not all customers do this.
> 2. Change the physical metadata - e.g. mark a table as non-updatable - this is enforced regardless. Some customers would do this.
What is the current default - update-able nor not?
> 3. Mark models as non-visible if users should not have access to them. This could be set at design time or on the vdb. Advanced customers would do this.
Perhaps moderately advanced. This is presented as best practice in
basic discussions with users as both a security concern and a method to
encourage encapsulation/loose-coupling.
> 4. Apply data roles at deploy-time to visible models. With roles/entitlement checking turned on a server is "locked down", since we are deny by default. Roles must be created for every VDB to provide any access. A few customers would do this.
>
> To clarify how permissions are applied, please see the MetaMatrix documentation or http://docs.jboss.org/teiid/7.1.0.Final/reference/en-US/html_single/#enti... for an updated explanation. In short, permissions are applicable to every visible resource and only checked against what is accessed by the top level of the user query. If visible virtual model B uses visible virtual model A which in turn accesses non-visible physical Z, then both A and B both should have roles/permissions applied because they are visible - B does not use the permissions of A. Z does not need roles/permissions because it cannot be targeted by a user query regardless.
>
> It has been asserted there is an inherent security flaw with this approach. That is simply not true. Since we are deny-by-default, adding visible models (such as B) to a VDB is NOT "insecure" until the Designer user (or deployer in MetaMatrix) adds permissions to the applicable data roles. Even then the notion of insecure would be based around the idea that permissions have been added inconsistently - for example, a particular column value from Z is readable in A, but not B. As often as not this could be described as a feature. This "application level" style of security makes it easy to present transformed values that would be otherwise be inaccessible with granular permissions.
>
> I became aware the other day that we are changing the default visibility on physical models. Just to make
IMO, phys models should remain visible by default. Making invisible
will make initial development/debugging that much more onerous.
> sure we understand that change better, please consider that having the default of physical models as non-visible only makes usage of VDBs without data roles (the majority use case) harder. It does not make vdbs with data roles more secure. Since we are deny by default, someone still has to take an explicit action to make a new model accessible when using roles. There is also an issue that any virtual update procedure is not a perfect substitute for a performing an update on a physical table. Virtual update procedures support insert into with a queryexpression 1 row at a time and do not allow referencing columns of view in either values or criteria. Forcing the use of virtual layers is not the right approach, it is merely a recommendation based upon the ease of use of the design-time visibility setting.
> With that said there have been a couple of issues raised relevant to security:
>
> TEIID-1220 - came about because of discussions with Paul where it was clear that breaking with legacy will help usability. Specifically having data role checking turned on requires every VDB to have roles, since this is now a design time and not a deploy time operation, it is especially onerous to go back and add roles as an afterthought to existing VDBs. The simple fix is to turn data role checking on by default and to only check roles if a vdb has them. This will be targeted to 7.1.1. An additional feature would be the ability to turn off role checking on a VDB through a managed property.
Agreed. If data role checking is on by default in Teiid, some global
state in the VDB should indicate whether or not it is "participating" in
data role usage. Perhaps that global state is the presence of at least
one role. Perhaps it's a discrete setting. The challenge with only
checking roles if the VDB has them is that a user can assume the system
is locked down because role checking is on but a VDB with no roles
defined will be wide open.
> TEIIDDES-568 - SYS and pg_catalog schemas are not yet covered by the data-role editor.
>
> TEIIDDES-577 - should non-visible models not be shown in the data-role editor?
I think non-visible models should show up in data-role editor but should
be identified as non-visible (grayed out or something). If a user is
applying data roles to a model and then later makes a decision to make
the model non-visible, it may be confusing for it to no longer display
in the editor. Also, would roles/permissions be preserved if the
modeler toggles visibility?
> In these latter cases there are a couple of alternative approaches that may help clarify some of the security confusion. The first observation is that the visibility mechanism is no longer easy to differentiate since both visibility and data roles are set at design time. A possible simplification is to not use the coarse grained notion of visibility for data access restrictions. Instead if a user wants to make a model (or any resource non-visible) that would be the same as creating a data role ("default") that does not have permissions for model. That role would need a mapping or a boolean attribute to denote that any authenticated user has the role.
Visibility is more than security. It's encapsulation. I don't think
users should use roles for that purpose - if that's what you're suggesting.
> Visibility checking is applied differently than roles - visibility also limited what is returned through the system tables and is also considered at resolving time (a non-visible table reference must be fully qualified). I can find no precedent for roles having a similar effect. That is all entries will be visible in metadata and resolvable against partial names and "SELECT *". There are other examples of being able to mark a table as hidden, which means that it will not show up in the system metadata but is otherwise accessible. If we do apply visibility likewise, then the visibility role concepts are distinct.
> Steve
> _______________________________________________
> teiid-dev mailing list
> teiid-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/teiid-dev
--
Ken Johnson
Sr. Product Manager
JBoss Middleware Business Unit
Red Hat, Inc
978.392.3917
ken.johnson(a)redhat.com
13 years, 11 months
Teiid/Teiid Designer Security
by Steven Hawkins
Hell all,
There is still a lot of confusion about security floating around. After another office conversation on Friday, it would be best to have an open discussion.
First some perspective. MetaMatrix documentation described the securitizing process in layers (an expanded version of this will be added to the Teiid docs):
1. Be selective about what metadata is imported - only modeled items can be accessed. Most if not all customers do this.
2. Change the physical metadata - e.g. mark a table as non-updatable - this is enforced regardless. Some customers would do this.
3. Mark models as non-visible if users should not have access to them. This could be set at design time or on the vdb. Advanced customers would do this.
4. Apply data roles at deploy-time to visible models. With roles/entitlement checking turned on a server is "locked down", since we are deny by default. Roles must be created for every VDB to provide any access. A few customers would do this.
To clarify how permissions are applied, please see the MetaMatrix documentation or http://docs.jboss.org/teiid/7.1.0.Final/reference/en-US/html_single/#enti... for an updated explanation. In short, permissions are applicable to every visible resource and only checked against what is accessed by the top level of the user query. If visible virtual model B uses visible virtual model A which in turn accesses non-visible physical Z, then both A and B both should have roles/permissions applied because they are visible - B does not use the permissions of A. Z does not need roles/permissions because it cannot be targeted by a user query regardless.
It has been asserted there is an inherent security flaw with this approach. That is simply not true. Since we are deny-by-default, adding visible models (such as B) to a VDB is NOT "insecure" until the Designer user (or deployer in MetaMatrix) adds permissions to the applicable data roles. Even then the notion of insecure would be based around the idea that permissions have been added inconsistently - for example, a particular column value from Z is readable in A, but not B. As often as not this could be described as a feature. This "application level" style of security makes it easy to present transformed values that would be otherwise be inaccessible with granular permissions.
I became aware the other day that we are changing the default visibility on physical models. Just to make sure we understand that change better, please consider that having the default of physical models as non-visible only makes usage of VDBs without data roles (the majority use case) harder. It does not make vdbs with data roles more secure. Since we are deny by default, someone still has to take an explicit action to make a new model accessible when using roles. There is also an issue that any virtual update procedure is not a perfect substitute for a performing an update on a physical table. Virtual update procedures support insert into with a queryexpression 1 row at a time and do not allow referencing columns of view in either values or criteria. Forcing the use of virtual layers is not the right approach, it is merely a recommendation based upon the ease of use of the design-time visibility setting.
With that said there have been a couple of issues raised relevant to security:
TEIID-1220 - came about because of discussions with Paul where it was clear that breaking with legacy will help usability. Specifically having data role checking turned on requires every VDB to have roles, since this is now a design time and not a deploy time operation, it is especially onerous to go back and add roles as an afterthought to existing VDBs. The simple fix is to turn data role checking on by default and to only check roles if a vdb has them. This will be targeted to 7.1.1. An additional feature would be the ability to turn off role checking on a VDB through a managed property.
TEIIDDES-568 - SYS and pg_catalog schemas are not yet covered by the data-role editor.
TEIIDDES-577 - should non-visible models not be shown in the data-role editor?
In these latter cases there are a couple of alternative approaches that may help clarify some of the security confusion. The first observation is that the visibility mechanism is no longer easy to differentiate since both visibility and data roles are set at design time. A possible simplification is to not use the coarse grained notion of visibility for data access restrictions. Instead if a user wants to make a model (or any resource non-visible) that would be the same as creating a data role ("default") that does not have permissions for model. That role would need a mapping or a boolean attribute to denote that any authenticated user has the role.
Visibility checking is applied differently than roles - visibility also limited what is returned through the system tables and is also considered at resolving time (a non-visible table reference must be fully qualified). I can find no precedent for roles having a similar effect. That is all entries will be visible in metadata and resolvable against partial names and "SELECT *". There are other examples of being able to mark a table as hidden, which means that it will not show up in the system metadata but is otherwise accessible. If we do apply visibility likewise, then the visibility role concepts are distinct.
Steve
13 years, 11 months
7.1 released
by Steven Hawkins
Hello all,
With the 7.1 release (announcement email still pending). trunk has become 7.2 and 7.1.1 should be worked on the 7.1.x branch. We don't expect much to happen in 7.2 until 7.1.1 is complete, so unless necessary you shouldn't need to make check-ins to trunk. This should keep the forward merge of 7.1.1 as clean as possible.
Steve
13 years, 11 months
Re: [teiid-dev] Modeling SOAP services
by John Doyle
Responses inline
----- "Steven Hawkins" <shawkins(a)redhat.com> wrote:
> What is the physical model procedure CountryInfoService backed by?
> The new WSConnection logic only supports the invoke procedure. Are
> you wanting to add some additional handling?
>
Yes, I'm behaving badly here, going outside the API. It's backed by the WS translator. The translator doesn't actually check what the procedure is called, so as long as the right values go in the right params, it works. This is easily changed.
> So you are promoting a fully layered approach where request, invoke,
> and response have independent place holders. I like that all three
> are there, but what I think Ramesh is getting at is that for simple
> input documents you could just have a single procedure encapsulate all
> three steps:
>
> create virtual procedure
> begin
> select t.* from (EXEC getOperationXXXRequestXML(proc.input1,
> proc.input2 ...)) as request, (EXEC invoke(request.result ...) as
> response, (EXEC getOperationXXXResponseTableXXX(response.result) as
> t)
> end
>
Yes, I think we're all on the same page here thankfully. That was the main thrush of my original question and I'm pleased we agree on this.
> The advantage is that the user can then do something similar to the
> old WS logic: select * from proc where proc.input1 = '1' and
> proc.input2 = 'foo'
>
> The downside, as John indicates, is that this only works when the
> input document can be formed from simple scalars. It also means that
> the response document is local to this execution. Without
> considerations for caching if there are multiple tables to extract
> from the response document you would want to use the same doc.
>
> For example to use the same response doc for a parent/child
> relationship: select p.* from (EXEC
> getOperationXXXRequestXML(proc.input1, proc.input2 ...)) as request,
> (EXEC invoke(request.result ...) as response, (EXEC
> getOperationXXXResponseTable1(response.result) as p inner join
> getOperationXXXResponseTable1(response.result) as c on p.id = c.pid)
>
> Although it would be better from a performance perspective if that
> join would be expressed as a single XMLTABLE instead...
There is a limit to the intelligence that's going to end up in the importer, and it certainly very limited in the short term. I think blogging and example/documentation is going to have to play a big role for this feature. Real world WSDLs are so varied and we can't really know what the user wants to do. But as you demonstrate, the beauty of the new language feature is that they can do what they want, and in a way that is more comprehensible.
>
> > XML using XMLTABLE and have access pattern on the all the scalar
> input
>
> Access patterns will also only work for non-lob inputs, which would be
> a problem for XML typed inputs.
Thanks, I have been runnning into this.
Thanks for the feed back guys.
>
> ----- Original Message -----
> From: "John Doyle" <jdoyle(a)redhat.com>
> To: "teiid-dev" <teiid-dev(a)lists.jboss.org>
> Sent: Monday, August 16, 2010 2:02:19 PM GMT -06:00 US/Canada Central
> Subject: [teiid-dev] Modeling SOAP services
>
> Moved from private thread to mailinglist:
>
> Close, but in my model the user executes something more like this:
>
> select t* from (EXEC getRequestXML(...)) as in, (EXEC execute(in) as
> out, (EXEC getResponseValues(out) as t))
>
> and in this case getResponseValues() is using XMLTABLE to create the
> procedure result. I can also get a lot more complex if either the
> request or response requires hierarchy with multiplicity, the it could
> become:
>
> select t* from (EXEC getParentRequest((EXEC getChildRequest(...) as
> child), ...) as parent,....
>
> In regards to using access patterns on the inputs, I would only use
> them in the event that multiplicity is >= 1. Real world WSDLs are
> pretty spotty in describing what's actually required for a service and
> what's not.
>
> ~jd
>
> ----- "Ramesh Reddy" wrote:
>
> > John,
> >
> > I am trying understand all this myself, as I am starting to write
> the
> > XMLTABLE blog. Yours is most advanced case in that!
> >
> > For some reason, this model of two procedures, that user need to
> > execute
> > is not sounding right to me. So, let me understand this correctly.
> > User
> > executes some thing like this right?
> >
> > select t* from (EXEC getRequestProcedure(...)) as in, (EXEC
> > getResponse(in))
> >
> > Please correct me, if understanding is wrong.
> >
> > thinking out loud - why not create response table based on the
> > response
> > XML using XMLTABLE and have access pattern on the all the scalar
> > input?
> > The one issue I see is input and output elements not matching.
> >
> > Ramesh..
> >
> > On Mon, 2010-08-16 at 10:13 -0400, John Doyle wrote:
> > > Hi guys,
> > >
> > > Last week I worked on changing the WSDL to source importer to
> work
> > with the new system functions. I've attached a model project that
> > contains a model for one operation of a WSDL in order to show the
> tact
> > I've taken, and want to get some feedback from you. It's not
> complete
> > yet, I need to add namespaces to the SQL, inputs/output for child
> > element XML, etc, but wanted to get feedback on the overall
> concept.
> > >
> > > The importer will create one physical model for each endpoint
> > defined in the WSLD, since each endpoint might need to be bound to
> a
> > different URL. I intended this physical model to used across the
> > generated views.
> > >
> > > The importer then creates a schema to contain views for each
> > operation. I added the schemas to the model because operations
> often
> > reuse the same type/element definitions across operations, but not
> > necessarily with the same XPaths. Containing the views within
> schema
> > allow me to create multiple views for any type/element with
> > encountering naming clashes.
> > >
> > > The views are created by parsing the declaration of the request
> and
> > response messages. A request message results in a procedure with
> > scalar inputs that produces and XML result. A response message
> > results in a procedure with XML in and scalar results. The
> procedures
> > are not yet accounting for child elements for messages with
> hierarchy
> > and multiplicity.
> > >
> > > Does this make sense, or did you have a different/better vision
> for
> > how a user would model around the new language features? As it
> stands
> > right now, I have been unable to create a procedure that executes a
> > service with this structure. Could be my limited abilities with
> SQL,
> > or that I've missed some limitation around our use of the XML type.
>
> > I've tried passing the requests to the physical procedure and
> > responses from the physical procedure using nested selects, and
> tried
> > holding them in variables to pass them, without success. I
> typically
> > end up with a validation error because I'm using a clob as a
> > criteria.
> > >
> > > I appreciate any and all feedback.
> > >
> > > ~jd
> _______________________________________________
> teiid-dev mailing list
> teiid-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/teiid-dev
> _______________________________________________
> teiid-dev mailing list
> teiid-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/teiid-dev
13 years, 11 months
Re: [teiid-dev] Modeling SOAP services
by Steven Hawkins
What is the physical model procedure CountryInfoService backed by? The new WSConnection logic only supports the invoke procedure. Are you wanting to add some additional handling?
So you are promoting a fully layered approach where request, invoke, and response have independent place holders. I like that all three are there, but what I think Ramesh is getting at is that for simple input documents you could just have a single procedure encapsulate all three steps:
create virtual procedure
begin
select t.* from (EXEC getOperationXXXRequestXML(proc.input1, proc.input2 ...)) as request, (EXEC invoke(request.result ...) as response, (EXEC getOperationXXXResponseTableXXX(response.result) as t)
end
The advantage is that the user can then do something similar to the old WS logic: select * from proc where proc.input1 = '1' and proc.input2 = 'foo'
The downside, as John indicates, is that this only works when the input document can be formed from simple scalars. It also means that the response document is local to this execution. Without considerations for caching if there are multiple tables to extract from the response document you would want to use the same doc.
For example to use the same response doc for a parent/child relationship: select p.* from (EXEC getOperationXXXRequestXML(proc.input1, proc.input2 ...)) as request, (EXEC invoke(request.result ...) as response, (EXEC getOperationXXXResponseTable1(response.result) as p inner join getOperationXXXResponseTable1(response.result) as c on p.id = c.pid)
Although it would be better from a performance perspective if that join would be expressed as a single XMLTABLE instead...
> XML using XMLTABLE and have access pattern on the all the scalar input
Access patterns will also only work for non-lob inputs, which would be a problem for XML typed inputs.
----- Original Message -----
From: "John Doyle" <jdoyle(a)redhat.com>
To: "teiid-dev" <teiid-dev(a)lists.jboss.org>
Sent: Monday, August 16, 2010 2:02:19 PM GMT -06:00 US/Canada Central
Subject: [teiid-dev] Modeling SOAP services
Moved from private thread to mailinglist:
Close, but in my model the user executes something more like this:
select t* from (EXEC getRequestXML(...)) as in, (EXEC execute(in) as out, (EXEC getResponseValues(out) as t))
and in this case getResponseValues() is using XMLTABLE to create the procedure result. I can also get a lot more complex if either the request or response requires hierarchy with multiplicity, the it could become:
select t* from (EXEC getParentRequest((EXEC getChildRequest(...) as child), ...) as parent,....
In regards to using access patterns on the inputs, I would only use them in the event that multiplicity is >= 1. Real world WSDLs are pretty spotty in describing what's actually required for a service and what's not.
~jd
----- "Ramesh Reddy" wrote:
> John,
>
> I am trying understand all this myself, as I am starting to write the
> XMLTABLE blog. Yours is most advanced case in that!
>
> For some reason, this model of two procedures, that user need to
> execute
> is not sounding right to me. So, let me understand this correctly.
> User
> executes some thing like this right?
>
> select t* from (EXEC getRequestProcedure(...)) as in, (EXEC
> getResponse(in))
>
> Please correct me, if understanding is wrong.
>
> thinking out loud - why not create response table based on the
> response
> XML using XMLTABLE and have access pattern on the all the scalar
> input?
> The one issue I see is input and output elements not matching.
>
> Ramesh..
>
> On Mon, 2010-08-16 at 10:13 -0400, John Doyle wrote:
> > Hi guys,
> >
> > Last week I worked on changing the WSDL to source importer to work
> with the new system functions. I've attached a model project that
> contains a model for one operation of a WSDL in order to show the tact
> I've taken, and want to get some feedback from you. It's not complete
> yet, I need to add namespaces to the SQL, inputs/output for child
> element XML, etc, but wanted to get feedback on the overall concept.
> >
> > The importer will create one physical model for each endpoint
> defined in the WSLD, since each endpoint might need to be bound to a
> different URL. I intended this physical model to used across the
> generated views.
> >
> > The importer then creates a schema to contain views for each
> operation. I added the schemas to the model because operations often
> reuse the same type/element definitions across operations, but not
> necessarily with the same XPaths. Containing the views within schema
> allow me to create multiple views for any type/element with
> encountering naming clashes.
> >
> > The views are created by parsing the declaration of the request and
> response messages. A request message results in a procedure with
> scalar inputs that produces and XML result. A response message
> results in a procedure with XML in and scalar results. The procedures
> are not yet accounting for child elements for messages with hierarchy
> and multiplicity.
> >
> > Does this make sense, or did you have a different/better vision for
> how a user would model around the new language features? As it stands
> right now, I have been unable to create a procedure that executes a
> service with this structure. Could be my limited abilities with SQL,
> or that I've missed some limitation around our use of the XML type.
> I've tried passing the requests to the physical procedure and
> responses from the physical procedure using nested selects, and tried
> holding them in variables to pass them, without success. I typically
> end up with a validation error because I'm using a clob as a
> criteria.
> >
> > I appreciate any and all feedback.
> >
> > ~jd
_______________________________________________
teiid-dev mailing list
teiid-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/teiid-dev
13 years, 11 months
Modeling SOAP services
by John Doyle
Moved from private thread to mailinglist:
Close, but in my model the user executes something more like this:
select t* from (EXEC getRequestXML(...)) as in, (EXEC execute(in) as out, (EXEC getResponseValues(out) as t))
and in this case getResponseValues() is using XMLTABLE to create the procedure result. I can also get a lot more complex if either the request or response requires hierarchy with multiplicity, the it could become:
select t* from (EXEC getParentRequest((EXEC getChildRequest(...) as child), ...) as parent,....
In regards to using access patterns on the inputs, I would only use them in the event that multiplicity is >= 1. Real world WSDLs are pretty spotty in describing what's actually required for a service and what's not.
~jd
----- "Ramesh Reddy" wrote:
> John,
>
> I am trying understand all this myself, as I am starting to write the
> XMLTABLE blog. Yours is most advanced case in that!
>
> For some reason, this model of two procedures, that user need to
> execute
> is not sounding right to me. So, let me understand this correctly.
> User
> executes some thing like this right?
>
> select t* from (EXEC getRequestProcedure(...)) as in, (EXEC
> getResponse(in))
>
> Please correct me, if understanding is wrong.
>
> thinking out loud - why not create response table based on the
> response
> XML using XMLTABLE and have access pattern on the all the scalar
> input?
> The one issue I see is input and output elements not matching.
>
> Ramesh..
>
> On Mon, 2010-08-16 at 10:13 -0400, John Doyle wrote:
> > Hi guys,
> >
> > Last week I worked on changing the WSDL to source importer to work
> with the new system functions. I've attached a model project that
> contains a model for one operation of a WSDL in order to show the tact
> I've taken, and want to get some feedback from you. It's not complete
> yet, I need to add namespaces to the SQL, inputs/output for child
> element XML, etc, but wanted to get feedback on the overall concept.
> >
> > The importer will create one physical model for each endpoint
> defined in the WSLD, since each endpoint might need to be bound to a
> different URL. I intended this physical model to used across the
> generated views.
> >
> > The importer then creates a schema to contain views for each
> operation. I added the schemas to the model because operations often
> reuse the same type/element definitions across operations, but not
> necessarily with the same XPaths. Containing the views within schema
> allow me to create multiple views for any type/element with
> encountering naming clashes.
> >
> > The views are created by parsing the declaration of the request and
> response messages. A request message results in a procedure with
> scalar inputs that produces and XML result. A response message
> results in a procedure with XML in and scalar results. The procedures
> are not yet accounting for child elements for messages with hierarchy
> and multiplicity.
> >
> > Does this make sense, or did you have a different/better vision for
> how a user would model around the new language features? As it stands
> right now, I have been unable to create a procedure that executes a
> service with this structure. Could be my limited abilities with SQL,
> or that I've missed some limitation around our use of the XML type.
> I've tried passing the requests to the physical procedure and
> responses from the physical procedure using nested selects, and tried
> holding them in variables to pass them, without success. I typically
> end up with a validation error because I'm using a clob as a
> criteria.
> >
> > I appreciate any and all feedback.
> >
> > ~jd
13 years, 11 months
7.1 CR2 status
by Steven Hawkins
Hello all,
We will release a CR2 tonight. Please hold off on check-ins unless they are necessary fixes. I'm doing some testing now and have a couple of fixes to make, so the build won't actually happen until later tonight.
Steve
13 years, 11 months
Security nomenclature
by Steven Hawkins
Hello all,
We should ensure that we have similar names for security concepts in Teiid/Designer/Docs. Here's where we are coming from:
MetaMatirx pre-5.5
entitlements - general term for applying CRUD permissions to a VDB.
entitlement - a named set of permissions and principles
data-policy - internal name for the permission collection of an entitlement. Internally these were referenced as policies in a system that resembled JAAS.
permission - an action and target
principle - a user or group identified by a unique name.
MetaMatrix 5.5
data roles - general term for applying CRUD permissions to a VDB, although the term "entitlements" was still in use in many places.
data role - a named set of permissions and groups - note that this was a restriction of the possible principles to only groups.
permission - same as before
Teiid Current
same as 5.5.
Moving forward I would propose purging the terms entitlement/entitlements. We should also correct the vdb-deployer.xsd so that data-policy becomes data-role. Optionally we could also consider converting the permission element children to attributes to condense the information a little. These would be a breaking changes, but should be done before the Designer feature is in place.
Steve
13 years, 11 months
code tables
by Steven Hawkins
Hello all,
With the changes to the mat view logic, code tables are now implemented as an implicit materialized view.
For example, lookup('t1', 'c2', 'c1', 1) gets logically turned into the following:
CREATE MATERIALIZED VIEW IF NOT EXISTS #CODE_T1.C1.C2 (c1 <c1 type>, c2 <c2 type> PRIMARY KEY (c1)) AS /*+ cache(pref_mem) */ select c1, c2 from t1;
SELECT c2 FROM #CODE_T1.C1.C2 WHERE c1 = 1;
Note that we do not generally support the creation of anything but a local temporary table or the use of the CREATE IF NOT EXIST/AS clauses. The additional clauses would be easy to add though.
The performance difference with the old implementation of code tables is that:
-There is minor additional overhead in creating the subsequent select, but this command skips all normal planning/parsing paths so the cost is negligible.
-There index structure is lg(n) for key lookup, not constant time (hash based).
-The index and table pages may not be in memory, but will prefer to remain there through soft references. For heavily used lookup functions, this should not introduce many additional disk accesses.
The advantages of this change are that:
-Since they are no longer forced to remain in memory, and are accessed through the buffer manager, there is no longer a practical need for explicit limits on code table creation.
-They will reuse the same replication logic as a regular implicit materialized view.
-Could be reported on/refreshed just like other materialized vies.
Another possibility though is to discourage the use of the lookup function in favor of creating an analogous materialized view. The advantages of this approach are:
-More control of the possible return columns. Code tables will create a mat view for each key/value pair. If there are multiple return columns it would be better to have a single mat view.
-More control of the cache hint - it also supports a TTL for automatic snapshot refresh.
-There is little difference in the performance. If a lookup is performed as an uncorrelated subquery, it will be turned into a constant prior to pushdown. If it is performed as a correlated subquery, it will be no different that using a correlated lookup function. Optionally it could be done as a join, in which case, the sort by the primary key has already been performed.
Steve
13 years, 11 months
