Looking for comments on teiiddes-196 - Change default for UDF property *deterministic* from false to true...
by Gerard Helbling
Hello,
I am looking for feedback/comments on teiiddes-196 - "Change default for UDF property *deterministic* from false to true to improve usability". This would change the default value in the Designer for the 'deterministic' property of new User Defined Functions from 'false' to 'true'. Because the default is 'false' and most UDFs are deterministic, it seems to get set incorrectly, probably because most users don't think to set it explicitly and leave it at the default setting. Setting a UDF to non-deterministic when it should be deterministic will cause the planner to miss opportunities to optimize.
On the other side, specifying a UDF as deterministic when it is non-deterministic could lead to unreliable results. I think this is not as likely to happen because a person developing a non-deterministic UDF will be very aware of that fact.
There is a bit more detail in the Jira.
Jerry
16 years, 11 months
6.1.0 update
by Steven Hawkins
Hello All,
Designer integration and basic internal testing are making progress, but we are going to wait for the XML connector changes before fully validating the release. The new target date is the 29th. Thanks to everyone for your efforts so far.
Steve
16 years, 12 months
configuration.xml property definition simplifications
by Steven Hawkins
FYI,
https://jira.jboss.org/jira/browse/TEIID-622 outlines a set of changes to remove attributes from property definitions and to replace the use of multiplicity with a an IsRequired attribute. This is considered low risk, since the changes brings the configuration in line with what is actually being used by the Designer (which doesn't use IsPreferred or multiplicity other than denoting required) and the parsing logic will still be tolerant of old definitions that use the IsHidden attribute or a required multiplicity.
Steve
16 years, 12 months
6.1.0 release update
by Steven Hawkins
Hello all,
We are in the process of testing and integrating the Teiid 6.1.0 snapshot. Based upon these efforts we are now looking at 5/27 as a possible release date - with a new snapshot to be posted tomorrow. The new release date should also accommodate including the remaining xml connector changes. The snapshot update will address issues with the connector sdk, the embedded example, and refines classloading options based upon TEIID-600. In the next couple of days we will also be branching 6.1.0 so that we more aggressively work on 6.1.1.
Thanks,
Steve
16 years, 12 months
How is "configuration.xml" is built?
by Ramesh Reddy
Previous version of the Teiid had single "configuration.xml" file to
define all the configuration for the Server. Teiid also maintained a
separate "configuration.xml" for the Embedded.
I have checked in some changes, where Teiid still have single
"configuration.xml" file at runtime. However, all the individual
"Connector Type" fragments are now specified under their own projects
under the "main/resources" directory with the name "${project}.xml",
with base "Connector" fragment defined under "connector-api" project.
During the build/kitting time all these files are brought together to
build the "configuration.xml" file, which can be either used in the
Server or Embedded.
So, if you are in need to edit any connector types, please edit these
individual files under their projects. Also, note that all dependencies
these connectors have will be defined under "ConnectorTypeClasspath",
which will also be computed based upon the dependencies defined for that
connector module.
Final content wise, this should be no different than what we have
before, just how we assemble this is changed. This work is done under
https://jira.jboss.org/jira/browse/TEIID-561
Ramesh..
17 years
Teiid 6.1.0 Schedule
by Ramesh Reddy
Currently Teiid is scheduled for 6.1.0 release on 5/21/2009. We still
have 18 more JIRA as of today 05/11/1009. If you have a JIRA assigned to
you please provide your estimates and plan completing them by prior to
above date. Otherwise, you have an option to push those out to 6.1.1
bucket.
6.1.1 will be bug fixing and integration branch that will be basis for
the product release, so please plan accordingly.
Thanks.
Ramesh..
17 years
Adding WSDL 2.0 Generation
by Ted Jones
In order to facilitate a REST architecture for our web service model based VDBs ( see TEIIDDES-122 ), we need to enable the HTTP binding spec support that WSDL 2.0 provides. Currently, our web service model generates WSDL 1.1. I would like to keep this behavior and add an option to the VDB web services tab to optionally generate WSDL 2.0. The WSDL 1.1 would still be generated according to the model definition, but we would convert to WSDL 2.0 using an Apache project called Woden . The 2.0 version of the wsdl would then be saved with the VDB. This way there would be no model changes required.
One issue I see here is that we could not re-import the WSDL without modifications to the importer for the web services model. That has always been something we have strived for in the past. Granted, we are not claiming support for WSDL 2.0 importing at this time but if we are generating it, it seems like we should go both ways?
Any thoughts on this approach to WSDL 2.0 generation?
Thanks,
Ted
17 years
