Re: Freezing localtimestamp and other time function on some value

On 04/12/2016 10:14 AM, Alex Ignatov wrote:
>
>
> On 12.04.2016 19:45, David G. Johnston wrote:
>> On Tue, Apr 12, 2016 at 8:37 AM, Alex Ignatov
>> <<mailto:a.ignatov@postgrespro.ru>a.ignatov@postgrespro.ru>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).

The basic problem I see is that time does not stand still and a test
setup that assumes it does is not testing the real world your
application lives in. I see no real application for your proposal, I
know you disagree, I just cannot see it being useful to the majority of
users.

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


--
Adrian Klaver
adrian.klaver@aklaver.com