[jira] [Commented] (OLINGO-527) Is there any possible ay to reduce build response time of JPA query
[
https://issues.apache.org/jira/browse/OLINGO-527?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14318669#comment-14318669
]
Karuna Joshi commented on OLINGO-527:
-
Hi Chandan,
around 15000 records fetched from DB. we tried to set the limit to fetch around
3000 record at a time using eclipselink fetch-size property in
persistence.xml. we also try to use SKIP AND TOP in data request url.
The main problem is, even if we bear the delay in large number of records being
fetched (in subsequent hit its taking very less time ) , the time taken to
build the response for such a huge dataset is very large. Time taken to build
the response is large, when we use $expand in request. But without expand if
the same number of records are fetched, build response time is very very less.
I looked into the olingo code where it build response and found that major time
is taken in AtomEntryEntityProducer::append function. which is being called in
for loop for each entry in data map.
specially in this block of AtomEntryEntityProducer::append
else {
// write all links
if (!properties.isContentOnly()) {
appendAtomEditLink(writer, eia, data, selfLink);
appendAtomNavigationLinks(writer, eia, data);
} else {
appendAdditinalLinks(writer, eia, data);
}
// write properties/content
appendCustomProperties(writer, eia, data);
writer.writeStartElement(FormatXml.ATOM_CONTENT);
writer.writeAttribute(FormatXml.ATOM_TYPE,
ContentType.APPLICATION_XML.toString());
appendProperties(writer, eia, data);
writer.writeEndElement();
}
this block call appendAtomNavigationLinks() function which in turn call the
same append function in turn.
wanted to know is there anything we are missing, or should do to improve the
time taken to build the response ? can it be related to JPA entity relationship
we define ?
we can not use delta token feature as user can request any data any resource.
we can not be sure about what should be our delta in advance.
Thank you !
Is there any possible ay to reduce build response time of JPA query
Key: OLINGO-527
URL: https://issues.apache.org/jira/browse/OLINGO-527
Project: Olingo
Issue Type: Question
Reporter: Karuna Joshi
We have a very large data base and we are exposing the data using olingo
restful web service. when I compare, time taken to execute the same query via
jdbc connection and time taken by olingo, there is a significant difference.
Time taken by Olingo is very large.
Time taken to process JPA query + Time taken to build response is the total
time taken by olingo.
We try to tune the JPA queries using Query hints, but still build response
time is also very large.
I have a question :
Is there any way we can reduce the time taken to build the response ?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (OLINGO-549) POC: ODataV4 JPA Processor
[ https://issues.apache.org/jira/browse/OLINGO-549?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14318678#comment-14318678 ] Karuna Joshi commented on OLINGO-549: - What is the approximate time we can expect first release for JPA support ? POC: ODataV4 JPA Processor -- Key: OLINGO-549 URL: https://issues.apache.org/jira/browse/OLINGO-549 Project: Olingo Issue Type: New Feature Components: odata4-JPA Affects Versions: (JPA) V4 4.0.0-beta-01 Reporter: Chandan V.A Assignee: Chandan V.A A proof of Concept for transforming JPA models into OData V4 compliant EDM models and supporting OData V4 protocol compliant operations into JPA 2.0/2.1 specific operations. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (OLINGO-574) Batch request inserting master/detail entities not working
Ivan Lucas Vargas created OLINGO-574:
Summary: Batch request inserting master/detail entities not working
Key: OLINGO-574
URL: https://issues.apache.org/jira/browse/OLINGO-574
Project: Olingo
Issue Type: Bug
Components: odata2-jpa
Affects Versions: V2 2.0.1
Environment: JPA (Hibernate), MacOS, tomcat 7, Oracle 12c database
Reporter: Ivan Lucas Vargas
According to the OData specification, we can relate post requests for inserting
entities in the same batch request:
http://www.odata.org/documentation/odata-version-2-0/batch-processing (item
2.2.1 - Referencing requests in a changeset)
Olingo should understand the master / detail relationship as per metadata
navigation properties and:
1. Insert the master entity and get the sequence Id of it (as per JPA mapping)
2. Before inserting the details entities, it should update this entities by
setting the master id into the details entities, and then persist to respect
the fk relationship
When sending the request, Olingo does not understand this relationship and does
not update the details entities with the Id of the master entity.
Details:
I'm trying to insert one entity with a list of another entity in the same batch
request. In my case, the post payload is:
--batch_98b2-5d17-73e4
Content-Type: multipart/mixed; boundary=changeset_3d94-0d7a-375d
--changeset_3d94-0d7a-375d
Content-Type: application/http
Content-Transfer-Encoding: binary
POST Orders HTTP/1.1
Content-ID: 1
DataServiceVersion: 2.0
Accept: application/atomsvc+xml;q=0.8,
application/json;odata=fullmetadata;q=0.7, application/json;q=0.5, */*;q=0.1
Content-Type: application/json
MaxDataServiceVersion: 3.0
{OrderId:-1,Customer:1}
--changeset_3d94-0d7a-375d
Content-Type: application/http
Content-Transfer-Encoding: binary
POST OrderItems HTTP/1.1
Content-ID: 2
DataServiceVersion: 2.0
Accept: application/atomsvc+xml;q=0.8,
application/json;odata=fullmetadata;q=0.7, application/json;q=0.5, */*;q=0.1
Content-Type: application/json
MaxDataServiceVersion: 3.0
{OrdemItemId:-2,OrderId:-1,ProductId:132}
--changeset_3d94-0d7a-375d--
--batch_98b2-5d17-73e4--
The idea here is to insert both entities. So, we have the OrderId: -1 and
OrderItemId: -2. This way, olingo will understand and generate the ids based on
the Oracle sequence mapped into the JPA entities. But, as far as I read till
now, the second changeset should reference the first changeset, by using the $
in the POST. So, it should be:
POST OrderItems HTTP/1.1 (original) - POST $1/OrderItems HTTP/1.1 (by
referencing the content-id: 1 of the first changeset)
Is this understanding correct? If yes, the second question is: My payload needs
to have the navigation link included? In this case, the payload sould be
something like:
{OrdemItemId:-2,OrderId:-1,ProductId:132} (original) -
{OrdemItemId:-2,OrderId:-1,ProductId:132, OrderDetails: {url: __deferred}}
Is this understand also correct? Or by the navigation link olingo will
understand that in the entity OrderItem, the property OrderId is a property
link and will resolve this referenced request and will fill the attribute
OrderItem.OrderId with the Order.OrderId that was already updated with the
sequence value got from the entity resolution of the first changeset?
The navigation property for this relationship generated by the $metadata is:
NavigationProperty Name=OrderDetails Relationship=pu.Order_OrderItem
FromRole=OrderItem ToRole=Order/
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
Re: byte[] support in JPA entities
Hello Aparna, Unfortunately it is not a possible solution to downgrade a dependency in Olingo. But perhaps it is possible that you package commons-codec in version 1.6 in your service (.war” file)? Kind regards, Michael On 12 Feb 2015, at 07:40, Khare, Aparna aparna.kh...@sap.com wrote: Dear Colleagues, We have a use case where we would deploy our content in SAP Hana Cloud Platform (HCP). We have a JPA entity which takes byte[] array. The olingo takes in dependency for commons-codec-1.6.jar. Whereas the HCP platform requires a dependency to commons-codec-1.4.jar . Because of which we are encountering the below error java.lang.NoSuchMethodError: org.apache.commons.codec.binary.Base64.isBase64(Ljava/lang/String;)Z org.apache.olingo.odata2.core.edm.EdmBinary.validateLiteral(EdmBinary.java:59) org.apache.olingo.odata2.core.edm.EdmBinary.internalValueOfString(EdmBinary.java:91) I understand this is not a bug with olingo but we would request incase you can please change the code instead of using isBase64(string) method which is not available in commons-codec 1.4, if you can switch to isArrayByteBase64(byte[]) which is present. This way hopefully we would be able to resolve the issue. Thanks, Aparna smime.p7s Description: S/MIME cryptographic signature
[jira] [Assigned] (OLINGO-574) Batch request inserting master/detail entities not working
[
https://issues.apache.org/jira/browse/OLINGO-574?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Bolz reassigned OLINGO-574:
---
Assignee: Michael Bolz
Batch request inserting master/detail entities not working
--
Key: OLINGO-574
URL: https://issues.apache.org/jira/browse/OLINGO-574
Project: Olingo
Issue Type: Bug
Components: odata2-jpa
Affects Versions: V2 2.0.1
Environment: JPA (Hibernate), MacOS, tomcat 7, Oracle 12c database
Reporter: Ivan Lucas Vargas
Assignee: Michael Bolz
According to the OData specification, we can relate post requests for
inserting entities in the same batch request:
http://www.odata.org/documentation/odata-version-2-0/batch-processing (item
2.2.1 - Referencing requests in a changeset)
Olingo should understand the master / detail relationship as per metadata
navigation properties and:
1. Insert the master entity and get the sequence Id of it (as per JPA mapping)
2. Before inserting the details entities, it should update this entities by
setting the master id into the details entities, and then persist to respect
the fk relationship
When sending the request, Olingo does not understand this relationship and
does not update the details entities with the Id of the master entity.
Details:
I'm trying to insert one entity with a list of another entity in the same
batch request. In my case, the post payload is:
--batch_98b2-5d17-73e4
Content-Type: multipart/mixed; boundary=changeset_3d94-0d7a-375d
--changeset_3d94-0d7a-375d
Content-Type: application/http
Content-Transfer-Encoding: binary
POST Orders HTTP/1.1
Content-ID: 1
DataServiceVersion: 2.0
Accept: application/atomsvc+xml;q=0.8,
application/json;odata=fullmetadata;q=0.7, application/json;q=0.5, */*;q=0.1
Content-Type: application/json
MaxDataServiceVersion: 3.0
{OrderId:-1,Customer:1}
--changeset_3d94-0d7a-375d
Content-Type: application/http
Content-Transfer-Encoding: binary
POST OrderItems HTTP/1.1
Content-ID: 2
DataServiceVersion: 2.0
Accept: application/atomsvc+xml;q=0.8,
application/json;odata=fullmetadata;q=0.7, application/json;q=0.5, */*;q=0.1
Content-Type: application/json
MaxDataServiceVersion: 3.0
{OrdemItemId:-2,OrderId:-1,ProductId:132}
--changeset_3d94-0d7a-375d--
--batch_98b2-5d17-73e4--
The idea here is to insert both entities. So, we have the OrderId: -1 and
OrderItemId: -2. This way, olingo will understand and generate the ids based
on the Oracle sequence mapped into the JPA entities. But, as far as I read
till now, the second changeset should reference the first changeset, by using
the $ in the POST. So, it should be:
POST OrderItems HTTP/1.1 (original) - POST $1/OrderItems HTTP/1.1 (by
referencing the content-id: 1 of the first changeset)
Is this understanding correct? If yes, the second question is: My payload
needs to have the navigation link included? In this case, the payload sould
be something like:
{OrdemItemId:-2,OrderId:-1,ProductId:132} (original) -
{OrdemItemId:-2,OrderId:-1,ProductId:132, OrderDetails: {url:
__deferred}}
Is this understand also correct? Or by the navigation link olingo will
understand that in the entity OrderItem, the property OrderId is a property
link and will resolve this referenced request and will fill the attribute
OrderItem.OrderId with the Order.OrderId that was already updated with the
sequence value got from the entity resolution of the first changeset?
The navigation property for this relationship generated by the $metadata is:
NavigationProperty Name=OrderDetails Relationship=pu.Order_OrderItem
FromRole=OrderItem ToRole=Order/
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (OLINGO-573) Olingo-server-extension with framework like approach for request handling
Michael Bolz created OLINGO-573: --- Summary: Olingo-server-extension with framework like approach for request handling Key: OLINGO-573 URL: https://issues.apache.org/jira/browse/OLINGO-573 Project: Olingo Issue Type: New Feature Components: odata4-server Affects Versions: (Java) V4 4.0.0-beta-02 Reporter: Michael Bolz Dear Community, Based on some discussions on OLINGO-482, there were several discussions merits of the Processor interface design and how it can be improved for sake of the service developer. Based on those discussions, I have implemented an alternative server side framework as extension. I added this in a separate branch called olingo-server-extension , you can also find it at [GitHub|https://github.com/apache/olingo-odata4/tree/olingo-server-extension] - This framework currently does not remove any previous Processor interfaces. As extension, these can be evaluated side by side for comparison, then we can decide on the direction best for Olingo in integrating into one module. - This framework designed specially to make the job of service developer as easy as possible to develop a OData service in the quickest time. - Tries to enforce the odata specification rules, where they need to be, before service implementer receives the request for processing - Moves Context URL processing away from service implementer - Automatically works with registered serializers based on the Content-Type defined on the request - Makes the building of response, based on request, such that it reflects the context of the request. Thus eliminates service implementer violating the spec expectations. - Provides $metadata schema parser in server side, using which a service implementer can define their metadata of the service, rather than current method using the object form. - Provides a full example based on TripPin service. I encourage you take look at the example service in the test section of this module and see how a sample service can be developed. We are looking for your comments and suggestions to improve upon this framework and your support of the design to carry forward. Please do reply, even that is either a +1 or -1 I understand that in this new framework, there single interface called ServiceHandler for service implementer to develop along with metadata. *If* multiple Processor interfaces is something we really do need, it is fairly straight forward and *easy* to extend the requests to use multiple interfaces as it is currently designed, so that any existing implementations are not broken. Please take an hour or two looking through this and provide your feedback, and suggestions to improve upon. I sincerely appreciate your time. Thanks. Ramesh.. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (OLINGO-562) Spring support for Olingo v4 server
[ https://issues.apache.org/jira/browse/OLINGO-562?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14318305#comment-14318305 ] Thierry Templier commented on OLINGO-562: - I added documentation and explanations for this support. See this link: https://templth.wordpress.com/2015/02/12/implementing-a-spring-custom-namespace-for-olingo/. Thierry Spring support for Olingo v4 server --- Key: OLINGO-562 URL: https://issues.apache.org/jira/browse/OLINGO-562 Project: Olingo Issue Type: New Feature Affects Versions: (Java) V4 4.0.0-beta-02 Environment: Java, Spring 4 Reporter: Thierry Templier Attachments: olingo-server-v4-spring.zip Hello, I have implemented a Spring support for Olingo v4 server side. It allows to define declaratively within your Spring configuration: * EDM provider (see file src/test/resources/applicationContext-edm-provider-namespace.xml) * HTTP handler (src/test/resources/applicationContext-http-handler-namespace.xml) A dedicated servlet is provided to get an instance of ODataHttpHandler from a Spring container and use it to handle request. You can find enclosed the corresponding code. I don't how such code can be integrated to Olingo. I think that it corresponds more to an extension than something to put in the Olingo core. Feel free to give me your feedback. Thierry -- This message was sent by Atlassian JIRA (v6.3.4#6332)
