Re: [teiid-dev] Hibernate reverse engineering
by Ted Jones
FWIW, I was able to reverse engineer using JBossTools 2.0.1 and Teiid 6.2. This was before the Teiid dialect was added to JBossTools. I documented the process here: http://community.jboss.org/wiki/RESTEasywithTeiid. The workaround I had to use do to the absence of the Teiid Hibernate dialect should work for the latest JBossTools as well. My example involved creating a SEAM web app, but that shouldn't be a requirement to get the Hibernate objects created
Ted
----- Original Message -----
From: "Amentra" <michael.walker(a)amentra.com>
To: "Ramesh Reddy" <rareddy(a)redhat.com>
Cc: teiid-dev(a)lists.jboss.org, "Jason Stokes" <jason.stokes(a)amentra.com>
Sent: Thursday, March 18, 2010 9:08:37 PM GMT -06:00 US/Canada Central
Subject: Re: [teiid-dev] Hibernate reverse engineering
It is typically run as an ant task, and behavior is tweaked via a
config file.
On Mar 18, 2010, at 3:15 PM, Ramesh Reddy <rareddy(a)redhat.com> wrote:
> Does Hibernate support command line reverse engineering?
>
> On Thu, 2010-03-18 at 16:26 -0500, Michael Walker wrote:
>> Thanks John. Let me know the JIRA and I'll follow it. I agree that
>> this seems like something we should be capable of currently.
>>
>>
>>
>> ______________________________________________________________________
>> From: John Doyle [jdoyle(a)redhat.com]
>> Sent: Thursday, March 18, 2010 5:16 PM
>> To: Michael Walker
>> Cc: Jason Stokes; teiid-dev(a)lists.jboss.org
>> Subject: Re: [teiid-dev] Hibernate reverse engineering
>>
>>
>>
>> Hey Mike,
>>
>> I just tried to reverse engineer a 6.2 teiid vdb, because I thought
>> your central thrust here was incorrect and that we had everything we
>> needed already, and it fails. The tooling can't find our dialect.
>> It's in all the lists, but the classes are not getting found.
>>
>> I believe this to be a defect, and that with the latest release of
>> JBossTools you should be able to reverse engineer a Teiid VDB. I'll
>> see about tracking down the issue and logging a Jira.
>>
>> ~john
>> ----- "Michael Walker" <michael.walker(a)amentra.com> wrote:
>>>
>>> To set the context: Hibernate's reverse engineering feature uses
>> standard JDBC database metadata to automatically generate all the
>> necessary Hibernate config files for working with the target database
>> in an O/R fashion
>> (https://www.hibernate.org/hib_docs/tools/reference/en/html/reverseenginee...
>> ).
>>>
>>> The getting started guide tells me that Teiid does not currently
>> support reverse engineering via Hibernate. This is somewhat
>> surprising, since Teiid generally supports all the typical JDBC
>> database metadata, making it easy to connect third-party client
>> tools,
>> etc.
>>>
>>> Does anyone on the Teiid development team know what it would take to
>> extend support for reverse engineering? How far off are we here?
>>>
>>> Apparently, Hibernate does provide a few options for working with
>> non-standard sources:
>>>
>>> 1. Create a custom hibernate.reveng.xml configuration file - This
>> will take care of small issues such as type mismatches, or exclusion
>> of certain tables
>>> 2. Extend Hibernate's JDBCMetaDataDialect class with your own
>> implementation
>>>
>>> I wonder if either option would allow us to get reverse engineering
>> working with Teiid without having to make significant change to Teiid
>> source. Thoughts?
>>>
>>>
>>>
>>>
>>
>>> _______________________________________________ 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
>
_______________________________________________
teiid-dev mailing list
teiid-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/teiid-dev
15 years, 10 months
Hibernate reverse engineering
by Michael Walker
To set the context: Hibernate's reverse engineering feature uses standard JDBC database metadata to automatically generate all the necessary Hibernate config files for working with the target database in an O/R fashion (https://www.hibernate.org/hib_docs/tools/reference/en/html/reverseenginee...).
The getting started guide tells me that Teiid does not currently support reverse engineering via Hibernate. This is somewhat surprising, since Teiid generally supports all the typical JDBC database metadata, making it easy to connect third-party client tools, etc.
Does anyone on the Teiid development team know what it would take to extend support for reverse engineering? How far off are we here?
Apparently, Hibernate does provide a few options for working with non-standard sources:
1. Create a custom hibernate.reveng.xml configuration file - This will take care of small issues such as type mismatches, or exclusion of certain tables
2. Extend Hibernate's JDBCMetaDataDialect class with your own implementation
I wonder if either option would allow us to get reverse engineering working with Teiid without having to make significant change to Teiid source. Thoughts?
<https://www.hibernate.org/hib_docs/tools/reference/en/html/reverseenginee...>
15 years, 10 months
"MaxResultRows" in the Connectors
by Ramesh Reddy
Teiid supports a property called "MaxResultRows" in Connector
properties, which defaults to 10,000 rows. The expected behavior of this
is to throw an exception when user queries more than 10,000 rows through
this connector.
However, this default behavior seems like a exceptional condition than
normal behavior expected by user any time. This *was* designed more for
the development time aid than the runtime.
Here is an example of community user tripping over it.
http://community.jboss.org/message/532560#532560
I propose, we change the default value of this property to zero (0) that
means the "MaxResultRows" will be set to "unlimited" in the default
scenario. If user requires to restrict max rows they can *explicitly*
set a value that they are comfortable with.
Any objections?
Thanks.
Ramesh..
15 years, 10 months
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..
15 years, 10 months
trunk looks good
by Steven Hawkins
Hello all,
Please note that common-internal was removed this morning. With that, we're pretty well cleaned up from the merge. It's exciting to see a clean build in under 4 minutes. We all owe Ramesh a beer (probably not all at once though).
Hopefully we're on track for the next milestone (or alpha) by the end of the week. Some time will need to be spent updating JIRA and considerable time with documentation. If there is anything you know of that should immediately be fixed/posted let's get it out there on the wiki.
Steve
15 years, 10 months
trunk is open for business
by Steven Hawkins
Hello all,
Common integration tests are not yet passing and the db project is not yet compiling. Other than that, it's ready to go.
Steve
15 years, 10 months
trunk freeze
by Steven Hawkins
Hello all,
Please hold off on checkins to trunk today and tomorrow until after we're merged.
Thanks,
Steve
15 years, 10 months
Proposed Schema for "ConfigurationInfo.def" file
by Ramesh Reddy
Based on the JCA changes to the VDB artifact and its configuration the
current "ConfigurationInfo.def" file needs to be modified.
I have attached the XML schema and a sample XML file showing the new
format of this file. This format closely resembles the old format with
few additions to lot of removal of other elements.
This same XML file will serve as
1) Configuration for the VDB
2) Configuration to define a "Dynamic VDB"
3) Will serve as the persisted format in the container, when a user
modifies the associated connector bindings to a model using any
administrative tools.
Please take look at this and let me know if there are any suggestions to
improve upon.
Thank you.
Ramesh..
15 years, 10 months
JCA merge
by Steven Hawkins
Hello all,
The time of the JCA branch merge to trunk is just about upon us (if not today, then tomorrow). There will be some rough edges initially, but things should be in good shape by the beginning of next week. I am hoping for usable kits shortly after that.
The Teiid Team
15 years, 10 months
Re: [teiid-dev] vdb connector binding names
by Steven Hawkins
All this is making me like the alternative scenario more. The only time an explicit source name (aka vdb specific connector binding name) other than the model name comes into place is with multi-source. And in that case we assume source name == connector binding name.
That gives us updated terminology:
a connector / connetor type - scope deployment wide
a connector binding / connector binding name == source name / jndi name - scope deployment wide
a model name - scope vdb
The additional requirement for multi-source is that they must keep connector binding names consistent across environments.
----- Original Message -----
From: "Ken Johnson" <kejohnso(a)redhat.com>
To: "Steven Hawkins" <shawkins(a)redhat.com>
Cc: "Ramesh Reddy" <rareddy(a)redhat.com>, "teiid-designer-dev" <teiid-designer-dev(a)lists.jboss.org>, "teiid-dev" <teiid-dev(a)lists.jboss.org>
Sent: Tuesday, March 2, 2010 10:50:12 AM GMT -06:00 US/Canada Central
Subject: Re: [teiid-dev] vdb connector binding names
I think I agree with this but have few clarifying questions points below.
Steven Hawkins wrote:
> We should be clearer on our terms. There are:
>
> a connector / connetor type - scope deployment wide
> a connector binding / connector binding name / jndi name - scope deployment wide
> a vdb specific connector binding name (aka source name) - scope vdb
>
> I'm suggesting that in non-multisource scenarios that model name == vdb specific connector binding name. If there are two models sharing the same connector that's fine.
>
Right. Each model is bound to the same connector but each has it's own
binding and thus it's own binding name.
The terminology is letting us down here again. To clarify the models are using the same connector binding. This is not the same as having the same connector and two connector bindings assigned to two different models.
> At deployment time assigning a connector binding to a model is sufficient for the non-multisource case. For
Here, will the vdb-specific-connector-binding-name come into play? That
is, will the binding gesture be a mapping of the
vdb-specific-connector-binding-name to the deployment-wide connector
binding name? Or will it be a binding of the model name to the
deployment wide connector binding name? I assume the latter but want to
be sure.
> multisource connector binding association, an additional "source name" attribute would be required. If the deployer has multiple multi-source models associated to the same set of connector bindings, it would be up to them to ensure that the source name was consistent.
>
This could potentially be managed by convention. That is, when using
multi-source models, those connector bindings need to be dedicated to
the multi-source models. They cannot be shared with standard,
single-source models or other multi-source models. It's a restriction
but should be have minimal impact on the broad user community.
> Alternatively we can infer the source name to be the connector binding name. This removes the need of having a vdb specific source name (which removes some desirable indirection), but this is how it worked in MMX anyway.
>
> ----- Original Message -----
> From: "Ramesh Reddy" <rareddy(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: Tuesday, March 2, 2010 9:32:49 AM GMT -06:00 US/Canada Central
> Subject: Re: [teiid-dev] vdb connector binding names
>
> Using the model name as the connector name is fine for default scenario,
> unless there are two models that are associated with same connector.
>
> On Tue, 2010-03-02 at 10:11 -0500, Steven Hawkins wrote:
>
>> Hello all,
>>
>> There seems to be some confusion over what's needed for connector binding names. To simplify things, there are two basic requirements - we need a known/stable/not environmentally dependent name for each connector binding used in a vdb and there also needs to be a way to associate that name with an actual JNDI resource. In the case of non-multisource models, the model name itself satisfies the first part. Only in the multisource scenario do we have an issue with needing an additional vdb specific name for the connector binding. As a first cut it seems fine to say that both the JNDI mapping and the vdb specific naming of multi-source connector bindings is a deployment time concern. Then the only design-time concerns become the model name and optionally marking a model multi-source enabled.
>>
>> Any thoughs?
>>
>> Steve
>>
>> _______________________________________________
>> 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
>
15 years, 10 months