Re: State of Perl-based database setup utilities for LedgerSMB 1.3

[Chris Travers <..hidden..>]

On Fri, May 27, 2011 at 4:06 PM, David F. Skoll <..hidden..> wrote:

> Exactly.
>
>> I am just hardly convinced this would be safe in practice.
>
> I think it will be very safe except for the readers of this list. :)
>
>> One of the real reasons this question arises is due to the automatic
>> sql generation that goes on when we are calling stored procedures.  In
>> essence we look into the system catalogs for the function name, pull
>> out the argument names and map those to input data.  Given that Perl
>> is a weakly typed language, there is a fundamental inability to
>> discern between overloaded functions of the same name and schema when
>> argument lists are different.
>
> OK, I can't comment on the internals because I'm not familiar enough
> with them.  But I think documented conventions will go a long way to
> avoiding problems.
>
>> So here you have a brittleness point which is out of the control of
>> the developers once it is deployed.  Currently it is believed that the
>> overall tradeoffs in reliability and robustness are worth it, but that
>> this is a positive tradeoff regarding reliability and robustness only
>> holds true if it is reasonable to run unit tests on production
>> databases when appropriate.
>
> Well... if the tests fail... then what?  I guess you have to revert?
> So you have a non-upgradeable system?

I would think that if the tests fail, the appropriate response to a
failed set of production tests is to start asking for help immediately
before you have to call into question the validity of your data.

Note my ideal is that production tests could be run at any time on the
production application.  This could occur when installing add-ons,
upgrading, etc. or even gaining information for a technical support
incident.

Best Wishes,
Chris Travers