4:13 a.m.
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..
6:42 p.m.
On Thu, 2010-01-28 at 21:13 -0600, Ramesh Reddy wrote:
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.
With the latest schema based changes for "vdb.xml" deployment file
inside the VDB, now we have introduced a new model type called
"FUNCTION" with which a UDF file will be defined for a VDB. If tooling
supports, user should be able to define multiple UDF files for a single
VDB going forward.
Currently, Teiid is still looking for single "FunctionDefinition.xmi"
file inside the VDB. Teiid will be modified to look for the above
information inside the xml file and look up UDF models based on
name == File(name+".xmi")
pattern in segregating the UDF models from others. Is this acceptable
for tooling side?
Thanks
Ramesh..
3:27 p.m.
On Mar 9, 2010, at 11:42 AM, Ramesh Reddy wrote:
Teiid will be modified to look for the above
information inside the xml file and look up UDF models based on
name == File(name+".xmi")
pattern in segregating the UDF models from others. Is this acceptable
for tooling side?
In later releases, we may want to revisit the assumption that this file has an XMI
extension, but from a tooling perspective I think that works for now.
Thanks,
JPAV
6:05 p.m.
Until Teiid 8.0 this will be it. We should not break the compatibility
for the users in the 7.x series. So if you think we need to change it
for some reason this may be perfect time.
Or We can have "path" attribute on the model as an optional property. If
available, we would use that. In the case this attribute is missing, I
can resort to below behavior.
Ramesh..
On Wed, 2010-03-10 at 08:27 -0600, John Verhaeg wrote:
On Mar 9, 2010, at 11:42 AM, Ramesh Reddy wrote:
> Teiid will be modified to look for the above
> information inside the xml file and look up UDF models based on
>
> name == File(name+".xmi")
>
> pattern in segregating the UDF models from others. Is this acceptable
> for tooling side?
In later releases, we may want to revisit the assumption that this file has an XMI
extension, but from a tooling perspective I think that works for now.
Thanks,
JPAV
6:55 p.m.
On Mar 10, 2010, at 11:05 AM, Ramesh Reddy wrote:
Until Teiid 8.0 this will be it. We should not break the
compatibility
for the users in the 7.x series. So if you think we need to change it
for some reason this may be perfect time.
Or We can have "path" attribute on the model as an optional property. If
available, we would use that. In the case this attribute is missing, I
can resort to below behavior.
Not sure I understand what a path attribute has to do with the file extension, but I'm
thinking based upon your compatibility concern, Teiid should not assume an XMI extension.
We'll supply the entire file name in the vdb.xml.
Thanks,
JPAV
6:57 p.m.
path == entire file name including the folder info
On Wed, 2010-03-10 at 11:55 -0600, John Verhaeg wrote:
On Mar 10, 2010, at 11:05 AM, Ramesh Reddy wrote:
> Until Teiid 8.0 this will be it. We should not break the compatibility
> for the users in the 7.x series. So if you think we need to change it
> for some reason this may be perfect time.
>
> Or We can have "path" attribute on the model as an optional property. If
> available, we would use that. In the case this attribute is missing, I
> can resort to below behavior.
Not sure I understand what a path attribute has to do with the file extension, but
I'm thinking based upon your compatibility concern, Teiid should not assume an XMI
extension. We'll supply the entire file name in the vdb.xml.
Thanks,
JPAV
7:57 p.m.
The "path" will *not* be required.
If we make this required, then we need to push this on all the models
including the dynamic vdb models that have have no path for their
models. Also, there is support of UDF in the Dynamic VDBs.
Designer can choose put this on every model. Previously we agreed that
this information will be in the one of the properties. Now, we have just
elevated this to a attribute on the "model" element.
Ramesh..
On Wed, 2010-03-10 at 12:49 -0600, John Verhaeg wrote:
On Mar 10, 2010, at 11:57 AM, Ramesh Reddy wrote:
> path == entire file name including the folder info
Okay, that's fine. Then let's just make the parameter required.
Thanks,
JPAV
8:26 p.m.
On Mar 10, 2010, at 12:57 PM, Ramesh Reddy wrote:
The "path" will *not* be required.
If we make this required, then we need to push this on all the models
including the dynamic vdb models that have have no path for their
models. Also, there is support of UDF in the Dynamic VDBs.
Sorry, I was forgetting that you can now have models that have no corresponding artifact
within the VDB. So, what I'm really getting at is we shouldn't have any default
behavior that assumes an XMI extension on a file when a path is specified; we'll
always provide the extension.
Thanks,
JPAV
5161
days inactive
5201
days old
8 comments
2 participants
participants (2)
-
John Verhaeg -
Ramesh Reddy