[JBoss JIRA] (TEIID-2666) Extend OData output formats, currently JSON and XML supported
by Ramesh Reddy (JIRA)
[ https://issues.jboss.org/browse/TEIID-2666?page=com.atlassian.jira.plugin... ]
Ramesh Reddy commented on TEIID-2666:
-------------------------------------
OData query always works in the context of a given entity, that may be reason there is no reason to qualify it, or look at metadata
> Extend OData output formats, currently JSON and XML supported
> -------------------------------------------------------------
>
> Key: TEIID-2666
> URL: https://issues.jboss.org/browse/TEIID-2666
> Project: Teiid
> Issue Type: Feature Request
> Components: Server
> Affects Versions: 8.4
> Environment: N/A
> Reporter: Cojan van Ballegooijen
> Priority: Trivial
>
> We would like to see the available output formats of the OData services be extended with CSV (Command Seperated Values) upon customer request.
> It would be great if we could extend it ourselves using for example XSLT or other transformation mechanism.
--
This message was sent by Atlassian JIRA
(v6.2.3#6260)
10 years, 7 months
[JBoss JIRA] (TEIID-2666) Extend OData output formats, currently JSON and XML supported
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-2666?page=com.atlassian.jira.plugin... ]
Steven Hawkins commented on TEIID-2666:
---------------------------------------
No I don't think there is a JIRA yet and I'm not entirely sure what the timeline looks like. You can go ahead and create a placeholder issue for this effort if you want. Ted Jones is one of our team members who is now a committer for olingo so we should have more responsiveness from that project.
> Extend OData output formats, currently JSON and XML supported
> -------------------------------------------------------------
>
> Key: TEIID-2666
> URL: https://issues.jboss.org/browse/TEIID-2666
> Project: Teiid
> Issue Type: Feature Request
> Components: Server
> Affects Versions: 8.4
> Environment: N/A
> Reporter: Cojan van Ballegooijen
> Priority: Trivial
>
> We would like to see the available output formats of the OData services be extended with CSV (Command Seperated Values) upon customer request.
> It would be great if we could extend it ourselves using for example XSLT or other transformation mechanism.
--
This message was sent by Atlassian JIRA
(v6.2.3#6260)
10 years, 7 months
[JBoss JIRA] (TEIID-2666) Extend OData output formats, currently JSON and XML supported
by John Muller (JIRA)
[ https://issues.jboss.org/browse/TEIID-2666?page=com.atlassian.jira.plugin... ]
John Muller commented on TEIID-2666:
------------------------------------
Thanks Steven, I wasn't aware of the move to Apache Olingo, but we'd really look forward to OData V4 aggregate support down the road. You have our use case exact: mobile apps consuming OData endpoints want a "clean" JSON object (single row) or array (multiple rows) with the entity name set to be the collection name and no metadata aside from the "nextLink"
Is there a JIRA feature request out for Olingo, or is that driven internally?
> Extend OData output formats, currently JSON and XML supported
> -------------------------------------------------------------
>
> Key: TEIID-2666
> URL: https://issues.jboss.org/browse/TEIID-2666
> Project: Teiid
> Issue Type: Feature Request
> Components: Server
> Affects Versions: 8.4
> Environment: N/A
> Reporter: Cojan van Ballegooijen
> Priority: Trivial
>
> We would like to see the available output formats of the OData services be extended with CSV (Command Seperated Values) upon customer request.
> It would be great if we could extend it ourselves using for example XSLT or other transformation mechanism.
--
This message was sent by Atlassian JIRA
(v6.2.3#6260)
10 years, 7 months
[JBoss JIRA] (TEIID-2263) makedep makenotdep hints should allow for more complicated scenarios
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-2263?page=com.atlassian.jira.plugin... ]
Steven Hawkins resolved TEIID-2263.
-----------------------------------
Resolution: Done
Implemented the view handling when the hint target starts with \@
There are a couple of corner case issues here, such as a potential conflict with hints that target tables starting with \@ and the hint can only match short names. However neither of these seem like too great of issues.
Logic to handle subqueries and unions will need to be added at some point, but the logic (and possibly all hints handling) will need to be moved to run prior to rewriting the query as it's possible for subqueries and even union branches to to be removed at that point. Alternatively we'd have to look at numbering or otherwise identifying query parts as part of resolving to be available for hint application.
> makedep makenotdep hints should allow for more complicated scenarios
> --------------------------------------------------------------------
>
> Key: TEIID-2263
> URL: https://issues.jboss.org/browse/TEIID-2263
> Project: Teiid
> Issue Type: Enhancement
> Components: Query Engine
> Reporter: Steven Hawkins
> Assignee: Steven Hawkins
> Fix For: 8.8
>
> Attachments: dep.patch
>
>
> In the option clause makedep and makenotdep take what are typically fully-qualified names and mark all matching tables/views in the query. This is not generally a good idea. We should allow for something akin to oracle global table syntax (view.)*table to drill down more specifically. Ideally we'd also account for subqueries and set operations as well.
--
This message was sent by Atlassian JIRA
(v6.2.3#6260)
10 years, 7 months
[JBoss JIRA] (TEIID-2666) Extend OData output formats, currently JSON and XML supported
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-2666?page=com.atlassian.jira.plugin... ]
Steven Hawkins edited comment on TEIID-2666 at 5/15/14 2:22 PM:
----------------------------------------------------------------
> It's really computationally intensive and expensive to have to reformat the JSON responses coming out of Teiid.
Sorry the formatting above was initially throwing me. So effectively you want to omit the metadata and change the result collection name. From what I can see there is odata 3 functionality somewhat similar to this with the odata metadata options (no metadata, minimal metadada, or full metadata). However none of those options seem to use the entity name for the collection name.
As we will likely be moving away from OData4j and toward olingo for odata 3 support, I don't think we should do more patching of odata4j than necessary.
was (Author: shawkins):
> It's really computationally intensive and expensive to have to reformat the JSON responses coming out of Teiid.
It's not clear to me from the above what exactly you are looking for. Can you provide more context as to what the result represents and how/why you get the alternate form? Generally this breaks down along the lines of:
1. Is there an OData4j formatting bug?
2. Are you suggesting that is a compatible with the spec?
3. Is this something that is simply custom?
> Extend OData output formats, currently JSON and XML supported
> -------------------------------------------------------------
>
> Key: TEIID-2666
> URL: https://issues.jboss.org/browse/TEIID-2666
> Project: Teiid
> Issue Type: Feature Request
> Components: Server
> Affects Versions: 8.4
> Environment: N/A
> Reporter: Cojan van Ballegooijen
> Priority: Trivial
>
> We would like to see the available output formats of the OData services be extended with CSV (Command Seperated Values) upon customer request.
> It would be great if we could extend it ourselves using for example XSLT or other transformation mechanism.
--
This message was sent by Atlassian JIRA
(v6.2.3#6260)
10 years, 7 months