On Sat, Dec 1, 2012 at 8:50 AM, Berend Tober <[email protected]> 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
------------------------------------------------------------------------------
Keep yourself connected to Go Parallel:
BUILD Helping you discover the best ways to construct your parallel projects.
http://goparallel.sourceforge.net
_______________________________________________
Ledger-smb-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/ledger-smb-devel
