Teiid JON/JOPR/RHQ Console
by Van Halbert
There is currently a jbedsp monitor project that represents the
beginning of the teiid console for configuration and monitoring. It
was was originally developed to work with MetaMatrix 5.5.3 (it was
provided as a tech preview) using JON and its distributed monitoring
architecture. It was later enhanced to work in EMBEDDED JOPR (the
console being delivered with JBoss AS 5), but it was still configured
to work with the old architecture in Teiid. However, the framework
in the jbedsp project is still applicable to developing the next
version to support Teiid embedded and Teiid Server. So I'm
planning on moving it tomorrow, unless something changes.
Van Halbert
Principal Software Eng.
Red Hat, Inc.
------
vhalbert(a)redhat.com
14 years, 8 months
6.2 M1 update
by Steven Hawkins
Hello All,
Now that we've got the new runtime module in shape, the examples/quick start updated, and encryption changes under control M1 will come out on Monday. There will be a few more check ins over the weekend cleaning up a few things at the connector level, but let a lead know if you have pending changes you want to get in. M2 will be targeted for 8/10 and will at least include the data command pass-through functionality from TEIID-669. The RC should be two weeks after that - please have all feature/enhancement work done at that time. The target release date in JIRA has been updated to 9/14 - Ramesh noticed it was too far out - but it's still a bit longer than 12 weeks given the timing of JBoss World.
Steve
14 years, 8 months
Re: [teiid-dev] [teiid-users] sql server time column
by Steven Hawkins
It's not an issue of whether it can be addressed at the connector level (see the response to Larry). It's a question of whether it's appropriate at the connector level.
----- Original Message -----
From: "Ramesh Reddy" <rareddy(a)redhat.com>
To: "Steven Hawkins" <shawkins(a)redhat.com>
Cc: "Warren Gibson" <wgibson(a)redhat.com>, "Paul Nittel" <pnittel(a)redhat.com>, "teiid-users" <teiid-users(a)lists.jboss.org>, "teiid-dev" <teiid-dev(a)lists.jboss.org>
Sent: Thursday, July 23, 2009 10:28:31 AM GMT -06:00 US/Canada Central
Subject: Re: [teiid-users] sql server time column
Is there anyway we can query the SQLServer for how it is basing the
time? If we can, can it be a connector capability?
On Thu, 2009-07-23 at 10:09 -0400, Steven Hawkins wrote:
> Several changes in Teiid have made our old behavior of allowing users to mark datatime columns from SQL Server/Sybase as time type in Teiid not work (it used to only fail in some situations with prepared statements). The issue is that SQL Server treats the default year for a time value as 1900 instead of 1970.
>
> My preferred approach is to have users represent the source datetime as a timestamp in Teiid (which is the default upon import), but perform type reconciliation in a virtual model using the following expression - convert(timestampadd(SQL_TSI_YEAR, 70, <source datatime>), time).
>
> To ensure this doesn't harm performance I can add a rewrite rule to perform the inversion of timestampadd.
>
> Since it includes the time type, this isn't an issue with SQL Server 2008.
>
> Steve
> _______________________________________________
> teiid-users mailing list
> teiid-users(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/teiid-users
14 years, 9 months
Re: [teiid-dev] [teiid-users] sql server time column
by Steven Hawkins
There are workarounds that can be done (the previous approach was to change time literals to {ts'1900-01-01 <time>}), but I would rather not do them because:
1. customers are unlikely to have this scenario where a datetime artificially represents only time values - we forced the issue with our bqt testing
2. if you just wrap the column in the appropriate expression at the connector level, you miss out on our rewriter enhancements.
----- Original Message -----
From: "Larry O'Leary" <loleary(a)redhat.com>
To: "Steven Hawkins" <shawkins(a)redhat.com>
Cc: "Warren Gibson" <wgibson(a)redhat.com>, "Paul Nittel" <pnittel(a)redhat.com>, "teiid-users" <teiid-users(a)lists.jboss.org>, "teiid-dev" <teiid-dev(a)lists.jboss.org>
Sent: Thursday, July 23, 2009 10:02:58 AM GMT -06:00 US/Canada Central
Subject: Re: [teiid-users] sql server time column
On Thu, 2009-07-23 at 10:09 -0400, Steven Hawkins wrote:
> Several changes in Teiid have made our old behavior of allowing users to mark datatime columns from SQL Server/Sybase as time type in Teiid not work (it used to only fail in some situations with prepared statements). The issue is that SQL Server treats the default year for a time value as 1900 instead of 1970.
>
> My preferred approach is to have users represent the source datetime as a timestamp in Teiid (which is the default upon import), but perform type reconciliation in a virtual model using the following expression - convert(timestampadd(SQL_TSI_YEAR, 70, <source datatime>), time).
Can this not be done in the connector?
--
Larry O'Leary <loleary(a)redhat.com>
Red Hat, Inc.
14 years, 9 months
sql server time column
by Steven Hawkins
Several changes in Teiid have made our old behavior of allowing users to mark datatime columns from SQL Server/Sybase as time type in Teiid not work (it used to only fail in some situations with prepared statements). The issue is that SQL Server treats the default year for a time value as 1900 instead of 1970.
My preferred approach is to have users represent the source datetime as a timestamp in Teiid (which is the default upon import), but perform type reconciliation in a virtual model using the following expression - convert(timestampadd(SQL_TSI_YEAR, 70, <source datatime>), time).
To ensure this doesn't harm performance I can add a rewrite rule to perform the inversion of timestampadd.
Since it includes the time type, this isn't an issue with SQL Server 2008.
Steve
14 years, 9 months
6.2 M1 update
by Steven Hawkins
Hello all,
Just a few updates. We had a bad build to fix on Friday, so we will shoot for tomorrow for an M1 build. SVN and JIRA mailing lists still seem to be down, but forum mailing lists are back up. The defect list for 6.2 has been shrinking at a good rate and should be in the low thirties by the time we're looking at M2.
Steve
14 years, 9 months
Re: [teiid-dev] Teiid Server Kit
by John Doyle
I like teiid-runtime. teiid-engine occurred to me, but I think runtime is better.
~jd
----- "Ramesh Reddy" <rareddy(a)redhat.com> wrote:
> As part of 6.2 release Teiid is will be providing a "Server" kit for
> community. A initial version of this kit is available now!
>
> The build scripts are modified such that current "embedded" kit can
> now
> be used in multi-purpose mode, where it can support either "embedded"
> mode or standalone server mode.
>
> The way user invokes the environment defines how the run time is
> started.
>
> 1) If user specifies embedded URL on the connection string, the Teiid
> runtime is loaded into host JVM, and user has Teiid Embedded
>
> 2) If server is manually started, and then if user uses the Server
> specific URL as the connection string, the client program can connect
> to
> Teiid Server instance over the socket.
>
> Startup scripts for running the server are provided in the "bin"
> folder.
> This kit is still under progress and you can monitor it under
> https://jira.jboss.org/jira/browse/TEIID-259. Try it out, give us
> your
> feedback.
>
> Now, that we have single kit for both Embedded and Server, it is
> confusing to call it "embedded" kit. So, we need to re-name this kit
> to
> something else. Teiid leads would like call this just
> "teiid-runtime",
> but are open for other suggestions. So, if you have other suggestions
> for name let's hear um?
>
> Thanks
>
> Ramesh..
>
>
> _______________________________________________
> teiid-dev mailing list
> teiid-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/teiid-dev
14 years, 9 months
Integration Testing
by Van Halbert
Since there is already a teiid-test-integration project, what should
this new integration testing project be called? The current teiid-
test-integration appears its tests are related to testing the sdk.
Maybe we should have a different organization (grouping) of what we're
testing (i.e., driver, sdk, connectors) so we can tell what we have /
find and where to contribute. Maybe create an integration test
project for each (i.e., sdk-test-integration, driver-test-
integration, etc.).
Thoughts / suggestions / comments.
Van Halbert
Principal Software Eng.
Red Hat, Inc.
------
vhalbert(a)redhat.com
14 years, 9 months
Re: [teiid-dev] Integration Testing
by John Doyle
----- "Larry O'Leary" <loleary(a)redhat.com> wrote:
> On Mon, 2009-07-13 at 16:11 -0500, Van Halbert wrote:
> > You are correct, no data source connection information will be in
> the
> > open. The product side will maintain its own data source
> > information. Part of the challenge to this new framework will be
> to
> > enable a contributor to run their tests against only the data
> > source(s) they have. The contributor most likely will not have
> all
> > the flavors.
>
> Which is why it is important for us to figure out the best way to
> organize the tests within the test framework. The idea would be that
> I
> can specify that I want the Salesforcce connector tests to be
> executed
> and by doing so, I must provide Salesforce credentials that can be
> used
> with the connector. Furthermore, it would be very nice if the
> schemas
> used with the Salesforce connector could be the same as the ones used
> with the other connectors so that a basic/common test case suite
> would
> apply. For example, creating a script that could be responsible for
> populating Salesforce with equivalent schema and data such as BQT so
> that type testing can be executed in the same manner that it is
> against
> PostgreSQL. This of course shouldn't be a requirement but a goal so
> that new schemas don't have to be created and maintained across each
> connector.
>
I agree with this as a goal, but I don't think it's going to be possible in this particular case. To the best of my knowledge there is no way to programmatically modify the metadata of a Salesforce app. Views built on top of the physical model of the default free developer Salesforce app are one possible way to to the common schema you're describing. Then the contributor would be able to specify his credentials and that should be enough.
Another limitation of this particular case that probably won't inform the larger framework, but I mention it anyway, is that modifications of the default Salesforce app were made to expose some of their non-standard types for testing that are not used in the default app. So no community user would be able to run all of the Salesforce tests unless they made manual modifications to their default app. This limitation could be clearly specified in the failure messages of the tests depending upon the modification, and it's not a wrinkle that I think we should be spending time on.
But like I said at the top, I agree with the goal you propose.
~jd
> --
> Larry O'Leary <loleary(a)redhat.com>
> Red Hat, Inc.
14 years, 9 months
Re: [teiid-dev] Integration Testing
by John Doyle
Just to make sure I understand this proposal, are we creating and opening a test framework, or a framework + tests?
I ask because I am thinking of how we can test some of the SAS services that I have been working with, SalesForce for now, but Google, Amazon, and Yahoo as well. All of these present similar concerns: we can't mock up the source, we don't want to share the credentials, they can be very slow (due to latency, API limitations, etc).
~jd
----- "Van Halbert" <vhalbert(a)redhat.com> wrote:
> A new integration testing project will be created to house the teiid
>
> integration tests. I'm starting this thread to open this topic
>
> up for discussion so that this process can begin to move forward.
>
> The following are some initial goals of this new project:
>
> - A new test integration project is going to be created, so that we
> start fresh, create a manageable project that is organized in a manner
>
> that we can make some sense what coverage we have. The goal of this
>
> new project is that it will be pushed to open source.
> - The new project will use the existing junit testing framework used
>
> on the product side. This framework enables the developers to
> create their own complex junit test (i.e., complex transaction test),
>
> but at the same time, allow bulk test sets to be run.
> - The new testing process will support the create/drop of database
> schemas and data refresh. So if a contributor can supply a database
>
> user with the right admin rights, the process will create a schema and
>
> all appropriate tables in order to run the test. Note: 1 schema
> will be created that will hold all necessary tables (i.e., bqt,
> mmfinancials, etc) required to support the tests.
> - To facilitate data loading/refreshing before a test, an extension to
>
> junit, DBUnit, will be used.
> - The existing test on the product side will be brought over, but in
>
> an organized fashion. This includes bulk test sets (mainly
> validating select type statements) and existing product junit tests.
>
>
> Additional Discussion points:
> - how best to organize tests so that we have some notion of what
> coverage we have
> - managing the project, ensuring additions by contributors, GSS,
> developers, etc. are done in a manner that ensures consistency
> - reducing the number of data source schemas we support (i..e, books,
>
> partssupplier, mmfinancials, bqt, and there are others). There's no
>
> reason to have that many different schemas to manage across all our
> different database types.
> - In order for the vdb artifacts to be usable in the open, the
> connector properties need to be cleaned out. The adminapi will be
>
> used to update the connector properties before the tests are run.
> This will require some manner of mapping the connector bindings to a
>
> specific datasource.
>
> --------------------------------------------------
>
> Here's the order of the tasks:
>
> - implement framework, have it ready for developers to start adding
> their junit tests
> - add the bulk set tests (baseline validation)
> - move over the existing junit tests, reworking those were the schema
>
> is no longer supported,
>
> As for any timeline on this project, your guess is as good as mine.
>
> This is one of those projects that doesn't get high priority, but it's
>
> really needed. And you go as fast as you can when you have the
> time.
>
>
> Please respond with your comments or suggestions.
>
> Van Halbert
> Principal Software Eng.
> Red Hat, Inc.
> ------
> vhalbert(a)redhat.com
>
>
>
>
> _______________________________________________
> teiid-dev mailing list
> teiid-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/teiid-dev
14 years, 9 months
