Login ProductsSalesSupportDownloadsAbout |
Home » Technical Support » Elevate Web Builder Technical Support » Support Forums » Elevate Web Builder General » View Thread |
Messages 11 to 20 of 37 total |
EWB 2 - Database AfterCommit |
Sat, May 16 2015 7:03 PM | Permanent Link |
Raul Team Elevate | <<
Walter Matte wrote: The Event - even if nested - means we could check the PendingCommits in the event and make a decision.at that time. So if you are not doing nested Transactions it would be equivalent to EWB 1 behaviour. >> It depends what you want the event to be - if it's the final event (i.e. all commits done) then pending commits will always be 0. This also ties into the current EWB2 logic where all of the events are batched together - you retry all (not just single one) and once they start working they all get sent one after another. If you want the event to be per commit then you can check pending but should not do retries yourself since framework is already sending pending event for you (OnCommitError is where you should cancel anything you don't need or want and call retries). Hence the event should be strictly to decide how your app is behaving (i.e. maybe you have a progress dialog that gets hidden once all are done or maybe you don't reload UI until all commits are known to be completed). If you have 1 commit event only then of course the 2 scenarios are the same. Nested is same as before - the "real" commit does not get triggered until you trigger the outermost/last commit (i.e. transactionlevel = 0). Anyways, let's see what Tim says. Raul |
Sun, May 17 2015 2:53 AM | Permanent Link |
Uli Becker | Raul,
> If you want the event to be per commit then you can check... (OnCommitError is where you should cancel anything you don't need or want and call retries) Assumed I have enabled a timer which checks PendingCommits and the commit is never successful, does PendingCommits stay at a value > 0? If I want to use a "TimeOut": how can I cancel a pending commit? The most common scenario would be: 1. The user enters a new record and clicks on "Save" 2. Commit is sucessful and the user get a message or 1. The user enters a new record and clicks on "Save" 3. Commit is not successful 4. Application maybe retries to commit - Timeout after 5 seconds e.g. 5. User gets a message, that the record could not be saved The question is, how to find a clean way to manage that. Thanks Uli |
Sun, May 17 2015 4:45 AM | Permanent Link |
Eivind | Uli...
I'm in need of exactly the same as you mention in your last post as I work with customers on very slow and lossy internet. I also need to perform some database tasks as well and need to know when data is saved. As for timeout, I added a timeout parameter to the FHttpRequest request object and that worked like a charm on all browsers I have tested it on. See this thread for details: http://www.elevatesoft.com/forums?action=view&category=ewb&id=ewb_general&msg=5793&page=1 |
Sun, May 17 2015 12:50 PM | Permanent Link |
Raul Team Elevate | On 5/17/2015 2:53 AM, Uli Becker wrote:
> Assumed I have enabled a timer which checks PendingCommits and the > commit is never successful, does PendingCommits stay at a value > 0? > If I want to use a "TimeOut": how can I cancel a pending commit? The whole connectivity issues will be interesting overall - one does need connectivity just to load the app but due to browser caching it's definitely possible one could load the app and then walk out of wifi range while using it (especially on mobile devices). Anyways, this is me looking at EWB2 source and Tim might have other views on how he expects it to work so take it with (big) grain of salt. FPendingCommits is decremented in EndCommit which is called from RequestComplete so yes PendingCommits remains > 0 until server request completes successfully. Cancel option seems to be not directly accessible at this time (unless i missed something). What i think needs to be done is basically to cancel the current requests from internal TServerRequestQueue and then clean up internal tdatabase commit state (basically what "EndCommit" does today - in fact might be ok to just call it). This also comes into play if the back-end issues an error (say DB key violation). Hence one would need to handle the commit failures both for "can't connect" errors and for actual "can't commit due to bad data" errors while connection is fine (i.e. other server requests would succeed still since we're connected). However with my current understanding of this i think it might be useful to have : 1 more callback event, 1 more public function and 1 more property : - server request timeout property at tdatabase level that is used for the internal TServerRequest to set request timeout - OnAllCommitsCompleted or similar callback that fires when EndCommit is called with FPendingCommits = 0.. It might not be a bad idea to have callback option in RequestComplete instead also for additional flexibility. - public function CancelCurrentCommit that you can call from OnCommitError and that does as described above (cancel serverrequest and call endcommit). All of these look very straightforward to add so might just experiment and see if i break something. For this i will cheat now and assume the items as described above exist: > The most common scenario would be: > > 1. The user enters a new record and clicks on "Save" > 2. Commit is sucessful and the user get a message Timer would work today - keep checking until PendingCommits=0. i personally like the OnAllCommitsCompleted callback concept though and once its called you proceed (i.e. inform user or remove progress etc). > 1. The user enters a new record and clicks on "Save" > 3. Commit is not successful > 4. Application maybe retries to commit - Timeout after 5 seconds e.g. OnCommitError is fired so you can decide to call RetryCommit if you want to retry or once you have tried enough call CancelCurrentCommit and inform user. If you (can) set the server request timeout then this will be called after that timeout so easiest might be to have a nice timeout option and just call RetryCommit right away but if you need another wait then yes you'd need a separate timer for that. > 5. User gets a message, that the record could not be saved From OnCommitError as before (once you decide no more retries). Raul |
Sun, May 17 2015 12:55 PM | Permanent Link |
Raul Team Elevate | On 5/17/2015 4:45 AM, Eivind wrote:
> As for timeout, I added a timeout parameter to the FHttpRequest request object and that worked like a charm on all browsers I have tested it on. I think it's still in TODO list but as you did last time we can easily add it ourselves until Tim implements it (in FHttpRequest and actually into the TXMLHttpRequest interface itself i think). Raul |
Sun, May 17 2015 5:47 PM | Permanent Link |
Uli Becker | Raul,
very good research and excellent conclusions. Let's.wait what Tim says. Uli |
Mon, May 18 2015 3:56 AM | Permanent Link |
Matthew Jones | Raul wrote:
> The whole connectivity issues will be interesting overall - one does > need connectivity just to load the app but due to browser caching > it's definitely possible one could load the app and then walk out of > wifi range while using it (especially on mobile devices). Your analysis is good, but I want to pick up on this because while generally true, it may not be. I think that if you pin the site bookmark to the home page, then it will be caching your page, but in any case you can open and go back to the browser at any point. More pertinently, you can use PhoneGap to make your EWB application into an App Store app, and in which case your connectivity might not be there at all at startup. These things are not important, because you should assume that you may lose a connection at any time, and that is what is important. Assume that any part of your connection may fail, and handle it appropriately. Basically, know what state your data is in, and don't assume anything. (I have one app which posts messages like to a newsgroup, but the API can't confirm if a message was posted, so double-posts are common on poor connections. Better service design would allow the app to ask if the last action completed properly or not. But this is not EWB specific, it is modern world norm.) -- Matthew Jones |
Mon, May 18 2015 10:15 AM | Permanent Link |
Tim Young [Elevate Software] Elevate Software, Inc. timyoung@elevatesoft.com | Uli,
<< 1. The user enters a new record and clicks on "Save" 3. Commit is not successful 4. Application maybe retries to commit - Timeout after 5 seconds e.g. 5. User gets a message, that the record could not be saved The question is, how to find a clean way to manage that. >> You'll get an OnCommitError event any time there's an issue with a commit, period. Tim Young Elevate Software www.elevatesoft.com |
Mon, May 18 2015 10:20 AM | Permanent Link |
Tim Young [Elevate Software] Elevate Software, Inc. timyoung@elevatesoft.com | Eivind,
<< I'm in need of exactly the same as you mention in your last post as I work with customers on very slow and lossy internet. I also need to perform some database tasks as well and need to know when data is saved. >> The important thing to remember here is: Saved <> committed. The commits queue up, so as far as the EWB application is concerned, you don't need to worry about whether something committed or not, other than knowing whether to retry commits (OnCommitError event) or give the user the option of retrying them (PendingCommits property). Tim Young Elevate Software www.elevatesoft.com |
Mon, May 18 2015 10:28 AM | Permanent Link |
Uli Becker | Tim,
> The question is, how to find a clean way to manage that. >> > > You'll get an OnCommitError event any time there's an issue with a > commit, period. Sure, but the question was, how to get a confirmation that the commit (save) was successful, IOW: have I to use a timer to wait for an OnCommitError to decide that? And how long? Uli |
« Previous Page | Page 2 of 4 | Next Page » |
Jump to Page: 1 2 3 4 |
This web page was last updated on Friday, December 6, 2024 at 05:39 PM | Privacy PolicySite Map © 2024 Elevate Software, Inc. All Rights Reserved Questions or comments ? E-mail us at info@elevatesoft.com |