1 2 Previous Next 16 Replies Latest reply on Sep 9, 2015 6:06 AM by jormond

    To commit or not commit, that is the question

    ibrahim_bittar

      Hello everybody

       

      These days I have been working on a development technique that allows to fully revert changes, not only in the master record but in the related ones too. Basically by not committing the master record until the user says so via a script.

       

      This has posed a number of challenges which I've been solving one by one and there is some empiric knowledge I've got from this experience but, I'd like to know if there is some under the hood information regarding the commit process.

       

      I feel like the child in the Albert Einstein's quote:

       

      “We are in the position of a little child entering a huge library, whose walls are covered to the ceiling with books in many different languages. The child knows that someone must have written those books. It does not know who or how. It does not understand the the languages in which they are written. The child notes a definite plan in the arrangement of the books, a mysterious order, which it does not comprehend but only dimly suspects.”

       

      May be locates or someone from this community could share how FM works regarding the commit process. I'd appreciate it a lot.

       

      Thanks in advance.

       

      Ibrahim

        • 1. Re: To commit or not commit, that is the question
          Markus Schneider

          I believe there are some documents - although I don't know if I got them from a conference, a webinar or from one of the manuals (wasn't there something in the training series?)

           

          I used this when transmitting records to another machine - if something failed, I could not commit to cancel..

           

          I did another test with this method when working on a FMGo App. That App is very simple, it creates a record from a Interface TO by getting the data into a scriptvariable, switching layout, add a new record an fill the field (only one) with the data from the variable, commits and go back to the original layout. Layouts are simple.

          For testing, I created another script that creates the data using a temporary relationship from the Interface TO without layout changes, like a single-line portal.

           

          while the difference on a desktop system wasn't wild - on iOS it was! Therefore this method becomes important when working on iOS devices

          • 2. Re: To commit or not commit, that is the question
            jormond

            Todd Geist has posted a lot, blogs, videos, demo files, etc...regarding Transactions in FM. Have you looked at his stuff. In some of his videos he gives some under the hood info that he has picked up from FM Engineers and others.

             

            geist interactive | FileMaker Transactions ( be sure to watch the videos on the right side of that article )

            http://www.modularfilemaker.org/module/transactions/

            A Transactional Approach in FileMaker Pro 13 | Colibri Solutions

            • 3. Re: To commit or not commit, that is the question
              Fred(CH)

              My understanding of english have some limits.... i hope i would not say too silly things here...

               

              Actually, when i have to do this, i mean "transactional commit", i am working with off-screen portals; what i found magic with portals is precisely the ability to roll back all changes with a simple Revert Record step.

               

              I never found better technique.

               

              Applying this, i had sometimes used another tip to create a calc on external table to see exactly which row was modified. In essence, i can have a "standard" unstored calc field on all tables where the formula is simply : Get(RecordState). I am mindful of possible performance penalties.

               

              Regardless, if necessary, the OnRecordSave triggered script can process only the row where this field is > 0.

               

              I suppose you all used these techniques before and if you have better one, i would be very interested to have more info about. The ability of the enduser to revert change is IMHO very very important. It is the reason why i *hate* when i have to Commit a record just for refreshing purposes, as it is, fortunately, rarely the case.

               

              Obviously, it is even more important to ensure that committed data are never contradictory : i mean, for instance, changes on table 1 reverted and changes on related table 2 stored.

              • 4. Re: To commit or not commit, that is the question
                jormond

                One of the most powerful things with the transactional approach, I can't remember now if Todd talks about it in one of his videos, or if I heard him talk about it at the SOFA user group meeting. The idea that you can throw an ID into a global to connect the relationship to the child table, send edits to the child record, clear the global, enter a different ID, send edits to that child record, and repeat over and over...then one single commit at the end. Check for errors. if there is an error, you can Revert Record, and everything reverts back to it's original state.

                 

                It helps with not having to have additional objects on the layout, hidden or not, and avoid layout/context changes.

                 

                Do some testing with it...there are a few things like creating records, where you won't be able to access the record or edited data until you commit the changes.

                • 5. Re: To commit or not commit, that is the question
                  Markus Schneider

                  that't the way I did with the FMGo App that became even faster afterwrds. I just wanted to avoid layout-switching - with that side-effect (-:

                  • 6. Re: To commit or not commit, that is the question
                    ibrahim_bittar

                    This is basically what I'm working on now, however, there are some script steps and functions that are based on committed data. For example GetNextSerialValue.

                     

                    I already have a list of functions that depend on committed data and others than not. It's not sharable today as they are scrap notes and some are still y my "cache memory", i.e. my head .

                     

                    I wanted to know if there is a formal list of functions and script steps that rely on committed data.

                     

                    For example, suppose you have 5 users creating records and you have a primary key field based on a serial number or a UUID. In some cases the serial would fail if users are creating records and there is not committed data.

                     

                    At this point I cannot say if it is a bug in my solution (probably) but something tells me that there si something more, like the Einstein's child.

                    • 7. Re: To commit or not commit, that is the question
                      ibrahim_bittar

                      Yes but creating related records is tricky and most of the time you'd need to use the hidden window technique. Old but useful.

                       

                      When I have this settled down and working I'll share a white paper so we all can comment and debug it.

                      • 9. Re: To commit or not commit, that is the question
                        ibrahim_bittar

                        Thank you very much, I'll take a look at it.

                        • 10. Re: To commit or not commit, that is the question
                          Fred(CH)

                          ibrahim_bittar a écrit:

                          […]most of the time you'd need to use the hidden window technique. Old but useful.[…]

                          Well, it is precisely what i would avoid, since Commit Record only commit open records on active window.

                           

                          To be clear, when i wrote "i am working with off-screen portals" i was talking about portals in the active window but outside the displayed area of a layout. The hidden area was not available before FileMaker 12 so the technique i am talking about was only easy since FileMaker 12.

                          • 11. Re: To commit or not commit, that is the question
                            jormond

                            Fred,

                            This statement may be misleading. Commiting the window will commit any related data that was edited/created to commit also.

                             

                            I also try to avoid opening additional windows whenever possible. Especially for solutions that may get used on Window. Spawning new windows on Windows will make your hard work look buggy and not well polished.

                            Fred(CH) wrote:

                            Well, it is precisely what i would avoid, since Commit Record only commit open records on active window.

                            • 12. Re: To commit or not commit, that is the question
                              electon

                              Ibrahim,

                              I don't think UUID would fail since it's not really sequential.

                              After all you could generate it on the fly and still create a related record within the transaction.

                              If you need to rely on creating records that need to be committed within the same transaction,

                              and still preserve the revert record capability then,I think you've got a problem.

                               

                              I think it depends on the relationships and how interconnected the records are where you want to know the next serial number from. Works ok in single user, not so in multi.

                              If the serials are auto increment on creation then I'd go ahead and create that record, claim the serial for yourself.

                              Other users will get their own. After all they're just serials. Ok, you will have gaps if you roll back, but is that a big problem?

                               

                              It can be done, I guess but without looking at it can't tell.

                              BTW. the Einstein quote, he was talking about the Universe not FileMaker

                              • 13. Re: To commit or not commit, that is the question
                                ibrahim_bittar

                                BTW. the Einstein quote, he was talking about the Universe not FileMaker

                                 

                                Sometimes a FileMaker problem can look that big to me hahaha , until I come here and everything looks normal again.

                                 

                                Thanks everybody for your suggestions, may be all I need is some more sleep .

                                • 14. Re: To commit or not commit, that is the question
                                  coherentkris

                                  Ray Cologon has done some seminal work on the topic and, in one of his demo files, demonstrated exactly what is happening under the hood between new record creation and commit. It is a variation of the magic key technique.

                                  The premise is that you can create new records and set values in the new records across a relationship that are never saved to the table until commit. If the new records are deleted prior to commit the transaction is cancelled. No extra windows needed either.

                                  See the duplicate hierarchy 2.0 file and take it apart.

                                  NightWing Enterprises - FileMaker Demos

                                  1 2 Previous Next