I want to insert a relatively large number of records to a table using server-side components.
Basically, I want to "copy" some records matching some criteria with some values changed.
My first thought was of using a DMI in combination with a stored procedure. The stored procedure would be called using a "custom" operationType. It would be in charge of iterating the dataset matching the criteria and of copying the records.
Would setRPCManager(originalRequest.getRPCManager) also work for operationType="custom", calling stored procedures? I.e. will the stored procedure be part of the transaction if setting setRPCManager(originalRequest.getRPCManager) to a operationType="custom"?
Another approach would be using server-side DSRequests: First fetching the matching records, then inserting the copies. But reading this post, especially:
I think this would be maybe more complicated than using a stored procedure. Since I cannot know in advanced the number of matching records, I would have to use pagination, i.e. use some similar technique as the one described in this thread.
What approach would you recommend me?
Using smartgwt 4.1p power.
Basically, I want to "copy" some records matching some criteria with some values changed.
My first thought was of using a DMI in combination with a stored procedure. The stored procedure would be called using a "custom" operationType. It would be in charge of iterating the dataset matching the criteria and of copying the records.
Would setRPCManager(originalRequest.getRPCManager) also work for operationType="custom", calling stored procedures? I.e. will the stored procedure be part of the transaction if setting setRPCManager(originalRequest.getRPCManager) to a operationType="custom"?
Another approach would be using server-side DSRequests: First fetching the matching records, then inserting the copies. But reading this post, especially:
Quote:
|
Originally Posted by Isomorphic
(Post 109253)
Generally speaking, what you're seeing is heuristics kicking in which are trying to do the best thing in the scenario where a client-side component such as a ListGrid is querying the server, does not have definitive knowledge of the number of rows in the table, and if it has made a request for rows that don't exist, is going to need some reasonable set of rows returned in order for the UI to function without having to turn around and issue another request immediately.
That's why you see things like like a fetch from 3000 to 3500 when there are really only 3342 rows converted to "LIMIT 2842, 500". The client clearly wants about 500 rows near the end of the table but didn't know there were only 3342 rows, so we fetch the last 500 and return that. Similarly when the requested range is entirely beyond the available rows, the range is converted to go from 0 up to the number of rows requested. The best approach for what you want to do (aside from sponsoring a true streaming API as we previously mentioned) is to have progressiveLoading off for the first request (so you get an accurate totalRows), then on for subsequent requests, and avoid ever setting startRow and endRow values that would fetch beyond the end of the range. |
What approach would you recommend me?
Using smartgwt 4.1p power.