[JBoss JIRA] (TEIID-2826) Change build to use zip translator packaging when building jboss kit
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-2826?page=com.atlassian.jira.plugin... ]
Steven Hawkins commented on TEIID-2826:
---------------------------------------
Just to get moving with the beta, I think I'll temporarily revert these last set of changes.
A few questions on the refinements. Why is the embedded assembly called module-dist.xml? Why are the kits/assemblies combined? It seems like we'd want them separated to avoid putting in exclusions.
Could the creation of the rar modules be done in just in a generic task, rather than requiring an assembly for each?
> Change build to use zip translator packaging when building jboss kit
> --------------------------------------------------------------------
>
> Key: TEIID-2826
> URL: https://issues.jboss.org/browse/TEIID-2826
> Project: Teiid
> Issue Type: Sub-task
> Components: Build/Kits
> Affects Versions: 8.7
> Reporter: Van Halbert
> Assignee: Ramesh Reddy
> Labels: Beta2
> Fix For: 8.7
>
>
> Change build to use zip translator packaging when building jboss kit
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 3 months
[JBoss JIRA] (TEIID-2870) Expand "allow-join" extension property on Foreign Key
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-2870?page=com.atlassian.jira.plugin... ]
Steven Hawkins resolved TEIID-2870.
-----------------------------------
Resolution: Done
updated the reference in the federated optimizations section to cover allow-join false/inner.
> Expand "allow-join" extension property on Foreign Key
> -----------------------------------------------------
>
> Key: TEIID-2870
> URL: https://issues.jboss.org/browse/TEIID-2870
> Project: Teiid
> Issue Type: Enhancement
> Components: Query Engine
> Affects Versions: 8.7
> Reporter: Ramesh Reddy
> Assignee: Steven Hawkins
> Priority: Minor
> Fix For: 8.7
>
>
> Currently "allow-join" property on a Foreign Key, defines if the joins based on that Foreign Key that are valid to push to the source or not, when JOIN capability is turned on at translator level. This feature is used in the MongoDB translator to allow JOINS to pushed to source.
> What I have seen is "allow-join" is blanket capability that says it supports all LEFT, RIGHT, INNER and CROSS JOINS. It is useful to define this capability in fine grained manner to allow each kind of JOIN explicitly to control the JOIN behavior.
> The need came from MongoDB translator, where INNER,LEFT are possible but CROSS and RIGHT are not.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 3 months
[JBoss JIRA] (TEIID-2887) MongoDB: mongodb DBCollection aggregate error
by Ramesh Reddy (JIRA)
[ https://issues.jboss.org/browse/TEIID-2887?page=com.atlassian.jira.plugin... ]
Ramesh Reddy reassigned TEIID-2887:
-----------------------------------
Assignee: Ramesh Reddy (was: Steven Hawkins)
> MongoDB: mongodb DBCollection aggregate error
> ----------------------------------------------
>
> Key: TEIID-2887
> URL: https://issues.jboss.org/browse/TEIID-2887
> Project: Teiid
> Issue Type: Bug
> Components: Misc. Connectors
> Affects Versions: 8.7
> Environment: Teiid 8.7 Beta1 with MongoDB
> Reporter: Ivan Chan
> Assignee: Ramesh Reddy
> Labels: teiid
>
> Here is my simple JSON object:
> "addresst" { "_id": 0,
> "name": "Duke Grant",
> "age": 38,
> "gender": "male",
>
> "address": { "_id": 0,
> "street": "345 Burnett Street",
> "city": "Nash",
> "state": "Rhode Island",
> "zip": 7384 }
> }
> And I define a schema like following:
> REATE FOREIGN TABLE addresst (custid integer PRIMARY KEY, name varchar(25), age integer, gender varchar(25)) OPTIONS(UPDATABLE 'TRUE');
> CREATE FOREIGN TABLE address (custid integer PRIMARY KEY, street varchar(50), city varchar(25), state varchar(25), zipcode varchar(6), FOREIGN KEY (custId) REFERENCES addresst (custid)) OPTIONS(UPDATABLE 'TRUE' , "teiid_mongo:MERGE" 'addresst');
> Got exception when trying to execute a query like following:
> select "MongoDB_addresst"."gender" as "MongoDB_addresst_gender",
> "MongoDB_address"."state" as "MongoDB_address_state"
> from "MongoDB"."addresst" "MongoDB_addresst"
> inner join "MongoDB"."address" "MongoDB_address" on ("MongoDB_addresst"."custid" = "MongoDB_address"."custid")
> group by "MongoDB_addresst"."gender", "MongoDB_address"."state"
> order by "MongoDB_addresst_gender", "MongoDB_address_state"
> limit 1000
> Exception:
> Caused by: com.mongodb.CommandFailureException: { "serverUsed" : "qa-mongodb.jaspersoft.com/172.17.1.48:27017" , "errmsg" : "exception: dotted field names are only allowed at the top level" , "code" :
> 16405 , "ok" : 0.0}
> at com.mongodb.CommandResult.getException(CommandResult.java:71)
> at com.mongodb.CommandResult.throwOnError(CommandResult.java:110)
> at com.mongodb.DBCollection.aggregate(DBCollection.java:1308)
> at org.teiid.translator.mongodb.MongoDBQueryExecution.execute(MongoDBQueryExecution.java:99)
> at org.teiid.dqp.internal.datamgr.ConnectorWorkItem.execute(ConnectorWorkItem.java:317)
> at org.teiid.dqp.internal.process.DataTierTupleSource.getResults(DataTierTupleSource.java:298)
> at org.teiid.dqp.internal.process.DataTierTupleSource$1.call(DataTierTupleSource.java:110)
> at org.teiid.dqp.internal.process.DataTierTupleSource$1.call(DataTierTupleSource.java:107)
> at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
> at java.util.concurrent.FutureTask.run(FutureTask.java:166)
> at org.teiid.dqp.internal.process.FutureWork.run(FutureWork.java:58)
> at org.teiid.dqp.internal.process.DQPWorkContext.runInContext(DQPWorkContext.java:273)
> at org.teiid.dqp.internal.process.ThreadReuseExecutor$RunnableWrapper.run(ThreadReuseExecutor.java:119)
> at org.teiid.dqp.internal.process.ThreadReuseExecutor$3.run(ThreadReuseExecutor.java:214)
> ... 3 more
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 3 months
[JBoss JIRA] (TEIID-2893) Add support for EAP 6.2/6.3
by Van Halbert (JIRA)
Van Halbert created TEIID-2893:
----------------------------------
Summary: Add support for EAP 6.2/6.3
Key: TEIID-2893
URL: https://issues.jboss.org/browse/TEIID-2893
Project: Teiid
Issue Type: Feature Request
Components: Build/Kits, Server
Affects Versions: 8.7
Reporter: Van Halbert
Assignee: Steven Hawkins
Priority: Blocker
Add support for EAP 6.2 or 6.3. The final version will not be known until EAP 6.3 release date is known.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 3 months
[JBoss JIRA] (TEIID-2892) OData buffers ALL rows from resultset before returning the first batch
by Ramesh Reddy (JIRA)
[ https://issues.jboss.org/browse/TEIID-2892?page=com.atlassian.jira.plugin... ]
Ramesh Reddy commented on TEIID-2892:
-------------------------------------
Caching apart are you seeing a significant delay in return of first batch with OData vs JDBC?
> OData buffers ALL rows from resultset before returning the first batch
> ----------------------------------------------------------------------
>
> Key: TEIID-2892
> URL: https://issues.jboss.org/browse/TEIID-2892
> Project: Teiid
> Issue Type: Bug
> Components: OData
> Affects Versions: 8.4.1
> Environment: Tested with Jboss DV 6.0.0. GA (enterprise edition) on Apple OSX 10.9.2 and Oracle Java VM 1.7.0_51.
> Reporter: Patrick Deenen
> Assignee: Steven Hawkins
> Attachments: logfiles.zip
>
>
> OData doesn’t batch internally opposed to JDBC which does. E.g. when in JDBC a query is done with a large result, only the first 2048 rows are physically fetched from the source database and only the first 200 rows (depending on client application) are returned. But when the same query is executed by the use of Odata ALL rows in the result set are physically fetched by DV and stored in the buffer. Even with the default Odata fetch batch size of 256. This makes the Odata interface very inefficient for large query results where one only is interessed in the first 256 rows.
> Attached you can find two log files which show the problem.
> The Odata query used is:
> http://localhost:8080/odata/PMA/EVENT_FACT?$filter=event_fact_id%20ge%207...
> Which is identical to the JDBC query used:
> select * from event_fact where event_fact_id between 747000000 and 747200000;
> In both cases the result contains 200.000 rows
> ODATA log information analysis (log file ’server start + odata batch 256.log’):
> row 4543 - 4657 - Start query
> row 4658 - 9030 - Read ALL results from result set and store them in buffer
> row 9031 - 9035 - Close DB connection
> row 9036 - 14647 - Clean buffers and create response?
> row 14648 - 14661 - return first batch and close connection
> JDBC log information analysis (log file ’server start + jdbc.log’):
> row 4925 - 5112 - Start query
> row 5113 - 5166 - Read ONLY the first 2048 results from result set and store them in buffer and return response
> row 5157 - 5214 - Close DB connection
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 3 months
[JBoss JIRA] (TEIID-2892) OData buffers ALL rows from resultset before returning the first batch
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-2892?page=com.atlassian.jira.plugin... ]
Steven Hawkins commented on TEIID-2892:
---------------------------------------
> BTW: It is is good that DV tries to cache query results, but I would not expect that the cache algoritme takes priority over returning the first batch of results to the client directly when they are available.
It does not.
> However need to see if behavior of TYPE_SCROLL_INSENSITIVE is to save all batches before the first batch is returned.
No, scroll insensitive will not pull all results before returning the first batch. However there is nothing that will inhibit it from processing to completion. So in general it's just a timing issue as to how much will be fetched before the client sees the first batch. Other than that a transaction can force processing to completion.
> OData buffers ALL rows from resultset before returning the first batch
> ----------------------------------------------------------------------
>
> Key: TEIID-2892
> URL: https://issues.jboss.org/browse/TEIID-2892
> Project: Teiid
> Issue Type: Bug
> Components: OData
> Affects Versions: 8.4.1
> Environment: Tested with Jboss DV 6.0.0. GA (enterprise edition) on Apple OSX 10.9.2 and Oracle Java VM 1.7.0_51.
> Reporter: Patrick Deenen
> Assignee: Steven Hawkins
> Attachments: logfiles.zip
>
>
> OData doesn’t batch internally opposed to JDBC which does. E.g. when in JDBC a query is done with a large result, only the first 2048 rows are physically fetched from the source database and only the first 200 rows (depending on client application) are returned. But when the same query is executed by the use of Odata ALL rows in the result set are physically fetched by DV and stored in the buffer. Even with the default Odata fetch batch size of 256. This makes the Odata interface very inefficient for large query results where one only is interessed in the first 256 rows.
> Attached you can find two log files which show the problem.
> The Odata query used is:
> http://localhost:8080/odata/PMA/EVENT_FACT?$filter=event_fact_id%20ge%207...
> Which is identical to the JDBC query used:
> select * from event_fact where event_fact_id between 747000000 and 747200000;
> In both cases the result contains 200.000 rows
> ODATA log information analysis (log file ’server start + odata batch 256.log’):
> row 4543 - 4657 - Start query
> row 4658 - 9030 - Read ALL results from result set and store them in buffer
> row 9031 - 9035 - Close DB connection
> row 9036 - 14647 - Clean buffers and create response?
> row 14648 - 14661 - return first batch and close connection
> JDBC log information analysis (log file ’server start + jdbc.log’):
> row 4925 - 5112 - Start query
> row 5113 - 5166 - Read ONLY the first 2048 results from result set and store them in buffer and return response
> row 5157 - 5214 - Close DB connection
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 3 months
[JBoss JIRA] (TEIID-2892) OData buffers ALL rows from resultset before returning the first batch
by Ramesh Reddy (JIRA)
[ https://issues.jboss.org/browse/TEIID-2892?page=com.atlassian.jira.plugin... ]
Ramesh Reddy commented on TEIID-2892:
-------------------------------------
I see that OData layer is returning a first batch of results. However need to see if behavior of TYPE_SCROLL_INSENSITIVE is to save all batches before the forst batch is returned.
> OData buffers ALL rows from resultset before returning the first batch
> ----------------------------------------------------------------------
>
> Key: TEIID-2892
> URL: https://issues.jboss.org/browse/TEIID-2892
> Project: Teiid
> Issue Type: Bug
> Components: OData
> Affects Versions: 8.4.1
> Environment: Tested with Jboss DV 6.0.0. GA (enterprise edition) on Apple OSX 10.9.2 and Oracle Java VM 1.7.0_51.
> Reporter: Patrick Deenen
> Assignee: Steven Hawkins
> Attachments: logfiles.zip
>
>
> OData doesn’t batch internally opposed to JDBC which does. E.g. when in JDBC a query is done with a large result, only the first 2048 rows are physically fetched from the source database and only the first 200 rows (depending on client application) are returned. But when the same query is executed by the use of Odata ALL rows in the result set are physically fetched by DV and stored in the buffer. Even with the default Odata fetch batch size of 256. This makes the Odata interface very inefficient for large query results where one only is interessed in the first 256 rows.
> Attached you can find two log files which show the problem.
> The Odata query used is:
> http://localhost:8080/odata/PMA/EVENT_FACT?$filter=event_fact_id%20ge%207...
> Which is identical to the JDBC query used:
> select * from event_fact where event_fact_id between 747000000 and 747200000;
> In both cases the result contains 200.000 rows
> ODATA log information analysis (log file ’server start + odata batch 256.log’):
> row 4543 - 4657 - Start query
> row 4658 - 9030 - Read ALL results from result set and store them in buffer
> row 9031 - 9035 - Close DB connection
> row 9036 - 14647 - Clean buffers and create response?
> row 14648 - 14661 - return first batch and close connection
> JDBC log information analysis (log file ’server start + jdbc.log’):
> row 4925 - 5112 - Start query
> row 5113 - 5166 - Read ONLY the first 2048 results from result set and store them in buffer and return response
> row 5157 - 5214 - Close DB connection
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 3 months
[JBoss JIRA] (TEIID-2892) OData buffers ALL rows from resultset before returning the first batch
by Ramesh Reddy (JIRA)
[ https://issues.jboss.org/browse/TEIID-2892?page=com.atlassian.jira.plugin... ]
Ramesh Reddy edited comment on TEIID-2892 at 3/11/14 12:08 PM:
---------------------------------------------------------------
I see that OData layer is returning a first batch of results. However need to see if behavior of TYPE_SCROLL_INSENSITIVE is to save all batches before the first batch is returned.
was (Author: rareddy):
I see that OData layer is returning a first batch of results. However need to see if behavior of TYPE_SCROLL_INSENSITIVE is to save all batches before the forst batch is returned.
> OData buffers ALL rows from resultset before returning the first batch
> ----------------------------------------------------------------------
>
> Key: TEIID-2892
> URL: https://issues.jboss.org/browse/TEIID-2892
> Project: Teiid
> Issue Type: Bug
> Components: OData
> Affects Versions: 8.4.1
> Environment: Tested with Jboss DV 6.0.0. GA (enterprise edition) on Apple OSX 10.9.2 and Oracle Java VM 1.7.0_51.
> Reporter: Patrick Deenen
> Assignee: Steven Hawkins
> Attachments: logfiles.zip
>
>
> OData doesn’t batch internally opposed to JDBC which does. E.g. when in JDBC a query is done with a large result, only the first 2048 rows are physically fetched from the source database and only the first 200 rows (depending on client application) are returned. But when the same query is executed by the use of Odata ALL rows in the result set are physically fetched by DV and stored in the buffer. Even with the default Odata fetch batch size of 256. This makes the Odata interface very inefficient for large query results where one only is interessed in the first 256 rows.
> Attached you can find two log files which show the problem.
> The Odata query used is:
> http://localhost:8080/odata/PMA/EVENT_FACT?$filter=event_fact_id%20ge%207...
> Which is identical to the JDBC query used:
> select * from event_fact where event_fact_id between 747000000 and 747200000;
> In both cases the result contains 200.000 rows
> ODATA log information analysis (log file ’server start + odata batch 256.log’):
> row 4543 - 4657 - Start query
> row 4658 - 9030 - Read ALL results from result set and store them in buffer
> row 9031 - 9035 - Close DB connection
> row 9036 - 14647 - Clean buffers and create response?
> row 14648 - 14661 - return first batch and close connection
> JDBC log information analysis (log file ’server start + jdbc.log’):
> row 4925 - 5112 - Start query
> row 5113 - 5166 - Read ONLY the first 2048 results from result set and store them in buffer and return response
> row 5157 - 5214 - Close DB connection
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 3 months
[JBoss JIRA] (TEIID-2892) OData buffers ALL rows from resultset before returning the first batch
by Patrick Deenen (JIRA)
[ https://issues.jboss.org/browse/TEIID-2892?page=com.atlassian.jira.plugin... ]
Patrick Deenen edited comment on TEIID-2892 at 3/11/14 11:05 AM:
-----------------------------------------------------------------
No, I just use a simple HTTP connection with java.net.HttpURLConnection to execute the URL mentioned in the text above. After that I download the results from the first HTTP response, that's it.
BTW: It is is good that DV tries to cache query results, but I would not expect that the cache algoritme takes priority over returning the first batch of results to the client directly when they are available.
was (Author: pdeenen):
No, I just use a simple HTTP connection with java.net.HttpURLConnection to execute the URL mentioned in the text above. After that I download the results from the first HTTP response, that's it.
> OData buffers ALL rows from resultset before returning the first batch
> ----------------------------------------------------------------------
>
> Key: TEIID-2892
> URL: https://issues.jboss.org/browse/TEIID-2892
> Project: Teiid
> Issue Type: Bug
> Components: OData
> Affects Versions: 8.4.1
> Environment: Tested with Jboss DV 6.0.0. GA (enterprise edition) on Apple OSX 10.9.2 and Oracle Java VM 1.7.0_51.
> Reporter: Patrick Deenen
> Assignee: Steven Hawkins
> Attachments: logfiles.zip
>
>
> OData doesn’t batch internally opposed to JDBC which does. E.g. when in JDBC a query is done with a large result, only the first 2048 rows are physically fetched from the source database and only the first 200 rows (depending on client application) are returned. But when the same query is executed by the use of Odata ALL rows in the result set are physically fetched by DV and stored in the buffer. Even with the default Odata fetch batch size of 256. This makes the Odata interface very inefficient for large query results where one only is interessed in the first 256 rows.
> Attached you can find two log files which show the problem.
> The Odata query used is:
> http://localhost:8080/odata/PMA/EVENT_FACT?$filter=event_fact_id%20ge%207...
> Which is identical to the JDBC query used:
> select * from event_fact where event_fact_id between 747000000 and 747200000;
> In both cases the result contains 200.000 rows
> ODATA log information analysis (log file ’server start + odata batch 256.log’):
> row 4543 - 4657 - Start query
> row 4658 - 9030 - Read ALL results from result set and store them in buffer
> row 9031 - 9035 - Close DB connection
> row 9036 - 14647 - Clean buffers and create response?
> row 14648 - 14661 - return first batch and close connection
> JDBC log information analysis (log file ’server start + jdbc.log’):
> row 4925 - 5112 - Start query
> row 5113 - 5166 - Read ONLY the first 2048 results from result set and store them in buffer and return response
> row 5157 - 5214 - Close DB connection
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 3 months