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

["David F. Skoll" <..hidden..>]

[Disclaimer: I am not intimately familiar with LSMB internals...]

On Fri, 27 May 2011 14:49:40 -0700
Chris Travers <..hidden..> wrote:

> What about installing add-ons into a database?  Do we care if
> something has changed and a third party add-on accidentally overloads
> a native LSMB defined function?

Well, that's the fault of the third-party add-on.  Add-ons shouldn't
overload native LSMB-defined functions.  As long as LSMB documents
the proper way to write add-ons ("use a unique prefix for your function
names, or don't overload anything beginning with lsmb_") then that's good
enough.

[...]

> How sure can we be that there are not functions which overload ones we
> automatically map arguments to?

Well, at some point you have to assume the sysadmin is sane and hasn't
made gonzo changes to the database or installed suspect add-ons.  You
can't plan for everything.  What you *can* say is "If you know enough to
mess with template0 or template1, then you will know enough to fix LSMB
when it breaks."

I would venture to guess that most LSMB users are not major PostgreSQL
gurus and simply use Pg because that's what LSMB wants.  Very few of
them should be mucking about with template[01].  (I *am* a major
PostgreSQL admin [not Guru] and I've never yet had to modify
template[01].)

> In PostgreSQL even template0 could be
> altered.  I suppose we could simply say that any alterations to
> template0 or template1 are entirely unsupported.

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?

[...]

> In which case, I think we'd have to highly recommend the installation
> of ledgersmb-tests, given the concerns mentioned above, would we not?

For that percentage of your audience who actually cares about PostgreSQL,
yes.  For the large majority who just use PostgreSQL because LSMB wants it,
I don't think it's a concern.

Regards,

David.