Re: Freezing localtimestamp and other time function on some value

Alex Ignatov <a.ignatov@xxxxxxxxxxxxxx> · Tue, 12 Apr 2016 20:14:25 +0300



    On 12.04.2016 19:45, David G. Johnston
      wrote:

    
        On Tue, Apr 12, 2016 at
            8:37 AM, Alex Ignatov <a.ignatov@xxxxxxxxxxxxxx> wrote:

        
                  On 12.04.2016 18:01, Adrian Klaver wrote:

                  
                >>I do it by having the date be one of the
                function arguments and have the default be something
                like current_date. When I test I supply a date to
                override the default. This allows for testing the
                various scenarios by changing the supplied date.

                
              With that approach you have to say application programmer
              - 'Hey dude, please edit this piece of code for my purpose
              and after that rollback it'.  I think that it is
              unacceptable in large project...
            

                CREATE FUNCTION do_some_date_based_stuff(reference_date
                date, other_args) [...]
            
            
              CREATE
                FUNCTION production_wrapper_for_above(other_args) [...]
            
            
              AS
                $$
            
            
              SELECT
                do_some_date_based_stuff(now(), other_args);
            
            
              $$
                ;
            
            
              Easy
                to test do_some_date_based_stuff since it has fewer if
                any external dependencies.  Shouldn't need to test the
                wrapper that simply calls the "do_some..." with a
                default value of the current date.
            
            
              You
                might be able to define an appropriate function
                signature that avoids having to write the wrapper though
                regardless there is no need to have a different
                environment for testing versus production if approached
                in this manner.  You just need to decide on the most
                desirable way to make it work.
            
            
              David
                J.
            
            
    I know that we can always write some wrappers etc, etc.

    This approach would failed if your do_some_date_based_stuff have no
    date args and contains calls say to now()(or other time function
    what possible can have fix value ) inside it.

    
    Also wrappers lead to  multiple code base,yours client side code
    needs to know what function  we should use - test or production.
    Also with your approach  application server needs to know its
    working mode test / prod

    
    You always should keep in mind that your application may run in test
    mode (future/past time) and maintain this code. While with my
    proposal you  can always use some time function(now or
    localtimestamp or whatever)  which you can  freeze at anytime on DB
    level, not operation system(using some 3rd libs) or
    application(using wrappers and other hacks).

    
    -- 
Alex Ignatov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company