Re: Why no LedgerSMB name space

On Sat, Dec 1, 2012 at 8:50 AM, Berend Tober <..hidden..> wrote:

I am wondering why all the LedgerSMB tables are not created in an
application-specific namespace, rather than the PUBLIC schema?

By default that is correct as far as what we do. It is quite possible to alter the user that creates the db to change the search path and we do support installing into a schema with a little extra work. Currently the decision is to allow which schema things go into to the implementation. If you want to install into a ledgersmb schema the following should work (logged into template1):

CREATE USER lsmb_setup WITH SUPERUSER PASSWORD = 'foo'; -- use this user/password for setup.pl
CREATE SCHEMA ledgersmb; -- must be done in template1

ALTER USER lsmb_setup SET search_path='ledgersmb, public';

Then in the ledgersmb.conf, you will want to set the following in the database section:

db_namespace = 'ledgersmb'

I have not tested this so there may be errors, but these should be avoidable. One may need to alter the default search path as well to include the ledgersmb schema. We are willing to fix bugs to make that work though.

proprietary data stored in separate data bases accessed by
different applications besides lsmb, but I also imagine that
there could be great value in having the data from those separate
application domains consolidated in a single data base but
segregated by name spaces corresponding to each application domain.

Agreed.

So for instance some application that did a really good job in
project management or some other complimentary-to-lsmb
application domain could be integrated (a little more) easily
with the financial system (than if separate data bases where used).

A ledgersmb namespace to contain all the lsmb data base entities
would be useful in this regard, I think, since there is only one
PUBLIC namespace, and lsmb really has no special place in the
universe to claim that as its home.

It would also help with regards to my other recent question (cf.
"Data base sanity checks")

Ok, so long-run I think we are actually likely to go in a different direction here, which is to package things in PostgreSQL extensions which can be installed in various schemas or even moved between them. This is likely to improve flexibility because different parts of the application could conceivably be installed into different schemas if needed. It would also simplify upgrade and restore from backup procedures since the schema would not be restored directly but merely created from the extensions setup.

Best Wishes,
Chris Travers