UDF Related Changes in 7.0 Teiid
by Ramesh Reddy
In Teiid user defined functions (UDF) are defined in a special
"FunctionDefinitions.xmi" file and this file deployed in the Teiid
runtime. Some times there is jar file associated with to provide
implementation classes, and if all the functions are "push down" then it
may not require it.
Lack of name space based functions like per VDB functions, or per
Connector kind of functions were long standing requests from users
(TEIID-231, TEIID-502).
Now in the container environment with its free standing nature this file
causes trouble in terms of deploying a UDF. In 7.0, we going to bundle
this "FunctionDefinitions.xmi" file inside the VDB artifact, such that
each VDB can have its own UDF functions and at the same time solve the
deployment issues.
The tooling in the Designer 7.0 will be modified to include
"FunctionDefinitions.xmi" file in the VDB and Teiid runtime will be
modified to look for the "FunctionDefinitions.xmi" file inside VDB and
deploy it accordingly.
Thanks
Ramesh..
14 years, 9 months
Re: [teiid-dev] [teiid-designer-dev] UDF Related Changes in 7.0 Teiid
by Ken Johnson
How might a user share a common "library" of functions across several
VDBs? I see the value of being able to scope to a single VDB. There's
also value in a shared set of functions (so they can be updated
centrally without requiring each VDB to be rebuilt and redeployed) .
Is there some way to provide users a choice of scoping functions to VDB
or treating them as a shared resource?
Thanks,
-Ken
Ramesh Reddy wrote:
> In Teiid user defined functions (UDF) are defined in a special
> "FunctionDefinitions.xmi" file and this file deployed in the Teiid
> runtime. Some times there is jar file associated with to provide
> implementation classes, and if all the functions are "push down" then it
> may not require it.
>
> Lack of name space based functions like per VDB functions, or per
> Connector kind of functions were long standing requests from users
> (TEIID-231, TEIID-502).
>
> Now in the container environment with its free standing nature this file
> causes trouble in terms of deploying a UDF. In 7.0, we going to bundle
> this "FunctionDefinitions.xmi" file inside the VDB artifact, such that
> each VDB can have its own UDF functions and at the same time solve the
> deployment issues.
>
> The tooling in the Designer 7.0 will be modified to include
> "FunctionDefinitions.xmi" file in the VDB and Teiid runtime will be
> modified to look for the "FunctionDefinitions.xmi" file inside VDB and
> deploy it accordingly.
>
> Thanks
>
> Ramesh..
>
> _______________________________________________
> teiid-designer-dev mailing list
> teiid-designer-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/teiid-designer-dev
>
--
Ken Johnson
Sr. Product Manager
JBoss Middleware Business Unit
Red Hat, Inc
978.392.3917
ken.johnson(a)redhat.com
14 years, 11 months
Teiid Admin API Access Changes
by Ramesh Reddy
In prior releases of Teiid, if a user wanted to access Teiid's Admin
API, they could get access to this API through JDBC connection. This was
a convenience method Teiid had provided. Internally Teiid created a
additional connection for admin.
With changes coming from management framework and security, even though
supporting the above is possible, it does seem right. What if, the
developer who has access to a JDBC connection can not have access to the
management or vice versa. Keeping this convenience access together under
single connection, also adds significant size to the Teiid's client JDBC
driver JAR to bundle the management framework.
So, we have been thinking to take these apart such that JDBC connection
only provides the access to the data side of the engine, where as a
separate "admin" connection will provide a management access. It will be
still possible for single user to be in the both roles, however they
would simply need to make two separate connections to access respective
functionality. This would let us package the admin access classes into a
separate jar file, so that this jar would only be required by users who
are dealing with admin functionality.
Please let us know if you have any comments.
Thanks.
Ramesh..
14 years, 11 months
7.0 MS 2
by Steven Hawkins
Hello all,
Teiid 7.0 MS 2 is now available - http://www.jboss.org/teiid/downloads.html. This milestone addresses numerous performance and source query generation issues, and enhances the Salesforce connector for use in dynamic vdbs. It will also be the last milestone prior to container integration. Keep the issues coming if you find anything.
The Teiid Team
14 years, 11 months
7.0 MS 2
by Steven Hawkins
Hello all,
We're looking at getting out MS 2 prior to the JCA merge and release a Designer MS 1 off of MS 2. If you have any pending work that should be committed prior to the milestone, let us know - otherwise we'll release on today or tomorrow.
Steve
14 years, 11 months
Re: [teiid-dev] Connectors, data source, and timestamps
by Steven Hawkins
Can you elaborate on your example? How did you set the time to 13:00 UTC? For my client in CST:
CREATE TABLE tswtz_test (x TIMESTAMP WITH TIME ZONE);
insert into tswtz_test (x) VALUES (FROM_TZ(TIMESTAMP '2010-01-12 13:00:00', '0:00'));
select x from tswtz_test;
returns:
2010-01-12 07:00:00.0
----- Original Message -----
From: "Larry O'Leary" <loleary(a)redhat.com>
To: "Steven Hawkins" <shawkins(a)redhat.com>
Cc: "teiid-dev" <teiid-dev(a)lists.jboss.org>
Sent: Tuesday, January 12, 2010 2:03:38 PM GMT -06:00 US/Canada Central
Subject: Re: [teiid-dev] Connectors, data source, and timestamps
On Tue, 2010-01-12 at 14:11 -0500, Steven Hawkins wrote:
> Java's notion of a timestamp is roughly the same as a dbms TIMESTAMP
> WITH TIME ZONE in that they both represent an absolute time. So for
> Teiid once we've read in a timestamp, regardless of its source, it's
> supposed to represent an absolute time (source timezone information is
> lost). For display and conversion purposes the the timezone of our
> timestamps is then taken to be the same as the default timezone of the
> Java instance we're running under.
>
> Connectors typically then do not have to concern themselves explicitly
> with time zones as long as the source contract is to create a
> timestamp object that represents the appropriate absolute time.
But from what I can tell, Oracle does not return a TIMESTAMP WITH TIME
ZONE as an absolute time. If for example I set the time portion to
13:00 UTC, this timestamp comes back as 13:00 CST when my JDBC driver
(client) is in CST. This is not the expected or same value as what was
inserted. I would expect the value returned would either be 07:00 CST
or 13:00 UTC.
> ----- Original Message -----
> From: "Larry O'Leary" <loleary(a)redhat.com>
> To: "teiid-dev" <teiid-dev(a)lists.jboss.org>
> Sent: Tuesday, January 12, 2010 12:59:43 PM GMT -06:00 US/Canada Central
> Subject: [teiid-dev] Connectors, data source, and timestamps
>
> I have been looking into some legacy issues regarding date/time values
> and time zone offsets. I am well aware that the DBMS recommendation is
> to store time values in a consistent, predetermined time zone. I think
> in principle this recommendation works but what about a federated query
> engine that has clients connecting from many different geographies?
>
> Also, how about the Oracle TIMESTAMP WITH TIME ZONE data type? It seems
> that this even complicates matters more?
>
> Are the connectors handling such logic? Do they need to? Does Teiid
> plan to offer a recommendation regarding setting and retrieving of time
> values and appropriate time zone or locale information?
--
Larry O'Leary
Middleware Support Engineering Group
Global Support Services
Red Hat, Inc.
loleary(a)redhat.com
1.866.LINUX70 (+1.314.336.2990) xt 81-62909
Office: +1.314.336.2909
Mobile: +1.618.420.7623
--
Delivering value year after year.
Red Hat ranks #1 in value among software vendors.
http://www.redhat.com/promo/vendor/
14 years, 11 months
Connectors, data source, and timestamps
by Larry O'Leary
I have been looking into some legacy issues regarding date/time values
and time zone offsets. I am well aware that the DBMS recommendation is
to store time values in a consistent, predetermined time zone. I think
in principle this recommendation works but what about a federated query
engine that has clients connecting from many different geographies?
Also, how about the Oracle TIMESTAMP WITH TIME ZONE data type? It seems
that this even complicates matters more?
Are the connectors handling such logic? Do they need to? Does Teiid
plan to offer a recommendation regarding setting and retrieving of time
values and appropriate time zone or locale information?
--
Larry O'Leary <loleary(a)redhat.com>
Red Hat, Inc.
14 years, 11 months
Teiid management and Security Control
by Ramesh Reddy
Hi,
With container integration of Teiid, the management of the Teiid is
being re-written using the Microcontainer(MC) based Management framework
and profile service[1]. Using this interface, JOPR [2] based tools can
be configured to build new management consoles for Teiid.
Prior releases Teiid provided role based security on Admin API methods,
where access to each API method was controlled by a role they are
specified with. Upon investigation of the MC's management framework and
profile service, it seems like they do not provide hooks to define the
fine grained role based security on individual management objects.
However, all the management can be secured under single role. So, a user
who has this admin role has access to all the services under the
management api. This is change from before as how Teiid would behave in
future releases in enforcing the security in management layer.
If Teiid management tooling is integrated with RHQ (JON), then this tool
can provide the additional fine grained security on top of this
management api[3].
Although, this is gap in functionality from before, with the benefits of
the new approach this seems to be OK. It is possible that in future
releases of management framework they might introduce some of this
functionality and Teiid can adopt at that time.
If you have any concerns please let us know.
Thanks
Ramesh..
[1] http://community.jboss.org/docs/DOC-13723
[2] http://www.jboss.org/jopr
[3] http://community.jboss.org/thread/146571
14 years, 11 months
Admin API Methods
by Van Halbert
Using Ramesh's list of which methods to keep/throw away for the 6.3
release, I only found 1 change that I thought was needed. That was
the "getTransactions" was in the throw away list. This is because,
if the "terminateTransaction" method is to remain, doesn't it need a
corresponding method to return the transactions in order to know/find
which transaction to terminate?
Other than that, nothing else.
Also, I started commenting on why the throwaway list of methods will
be gone to help explain/insight to the changes that are occurring.
//*******************
// methods to keep
//******************
configuration:
addVDB
changeVDBStatus
deleteVDB
exportVDB
getVDBs (from a vdb, the models can be obtained, and from a model,
the connector(s) can be found)
assignBindingToModel
importDataRoles
exportDataRoles
addUDF
deleteUDF
monitoring:
getQueueWorkerPools
getCaches
getSessions
getRequests (also enable monitor long running queries)
getSourceRequests
getTransactions
clearCache
terminateSession
cancelRequest
cancelSourceRequest
terminateTransaction
Others:
authenticateUser
//*****************
// Can these me removed?
//*********************
getRolesForGroup
getGroupsForUser
getGroups
assignRoleToGroup
removeRoleFromGroup
getDomainNames
getGroupsForDomain
//*******************
// Can be removed
//*********************
1. the connector type information will be defined in the ra.xml for
its respective connector rar file.
addConnectorType
deleteConnectorType
exportConnectorType
getConnectorTypes
getConnectorTypePropertyDefinitions
addConnectorArchive
exportConnectorArchive
2. JCA connectors will now be managed by the app server
setConnectorBindingProperty
addConnectorBinding
addConnectorBinding
deleteConnectorBinding
exportConnectorBinding
getConnectorBindings
getConnectorBindingsInVDB
startConnectorBinding
stopConnectorBinding
getConnectionPoolStats
3. Extension modules will now be deployed as part of the connector
rar file.
addExtensionModule
deleteExtensionModule
exportExtensionModule
getExtensionModules
extensionModuleModified
4. There is no longer be a configuration file, as in the past.
exportConfiguration
5. Process management is no longer part of Teiid
setProcessProperty
getProcesses
6. Start / Stop /Restart of Teiid engine is managed by the app
servers' management of JCA
shutdown
restart
7. Change in logging infrastrucure
getLogConfiguration
setLogConfiguration
setLogListener
Van Halbert
Principal Software Eng.
Red Hat, Inc.
------
vhalbert(a)redhat.com
14 years, 11 months
