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@xxxxxxxxxxxxxx>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).
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@xxxxxxxxxxx
--
Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
