Issue 2550852
Created on 2014-09-13 05:15 by smcgraw, last changed 2023-12-28 20:24 by rouilj.
File name |
Uploaded |
Description |
Edit |
Remove |
schema.patch
|
smcgraw,
2014-09-13 05:15
|
patch to back_postgresql.py for using pg schemas. |
|
|
schema_2.4.0_baseline.patch
|
rouilj,
2023-12-27 03:45
|
Stuart's patch applied to codebase during the 2.4.0 release. |
|
|
msg5142 |
Author: [hidden] (smcgraw) |
Date: 2014-09-13 05:15 |
|
The attached patch modifies backends/back_postgresql.py to allow
Roundup to create and use a roundup tracker in a Postgresql schema
(as opposed to requiring a separate database as formerly). This
allows multiple trackers to share a single database.
Having multiple trackers in separate schema of a single database
can simplify management of the trackers and offers options for
aggregated reporting.
The possibility was discussed in the roundup users email list,
"Data in postgres 'trackers' database, 'helpdesk' schema.",
Tom Ekberg <tekberg@uw.edu>, 2014-08-29.
The approach used largely follows the suggestions of John P.
Rouillard in
http://sourceforge.net/p/roundup/mailman/message/32777168/.
After applying the attached patch, use of a Postgresql schema
is requested by setting a RDBMS name value in the config file
with a dot and schema name following the database name. E.g.,
"roundup.myschema". (This is the same syntax used in Postgresql
and in standard SQL for referencing a schema.) If only the
database name is given, Roundup's behavior is as it was before.
When initializing a new tracker and the use of a schema is
specified, the database must already exist and the roundup user
must have been granted "create" privilege (allows the creation
of new schema) in the named database when "roundup-admin init"
is run.
The patch is incomplete (e.g., requires at least doc updates and
tests) but I wanted to verify the approach is acceptable before
spending more time on it. I am also not totally sure that the "."
in the rdbms name won't cause a problem elsewhere in the Roundup
code.
The patch is against the development version of Roundup as of
rev 5a59c723e57f (2014-09-06) but applies ok to the 1.5.0 version
with "patch --fuzz=3 ...".
|
msg5144 |
Author: [hidden] (ber) |
Date: 2014-09-15 09:29 |
|
Hi Stuart,
thanks for the patch. Let us see what others have to say about it.
Regards,
Bernhard
|
msg5511 |
Author: [hidden] (rouilj) |
Date: 2016-04-09 05:24 |
|
I realized this has languished for a while, but it looks reasonable to me.
|
msg7923 |
Author: [hidden] (rouilj) |
Date: 2023-12-27 03:45 |
|
Applied Stuart's patch to the 2.4.0 code. A few changes:
1. when checking to see if the db exists, add a conn.close() for
the schema branch.
2. add some more logging when a command errors. Include the
command and arguments being run.
3. add logging to schema path to parallel logging to non-schema path.
Also to set up a role/user (rounduptest) to be able to create a schema
in the database rounduptest run:
grant create on database rounduptest to rounduptest;
To add/remove createdb to a role use:
alter role rounduptest CREATEDB;
alter role rounduptest NOCREATEDB;
Also get a better name for db_schema_split(). Maybe get_db_schema_names().
TBD testing:
1) set up another rounduptest_schema db with rounduptest_schema user
2) verify that trying to initialize the db with
RDBMS_NAME=rounduptest_schema
user fails with Runtime Error with permission error.
3) initialize with the RDBMS_NAME=rounduptest_schema.rounduptest
4) run postgresql tests against using rounduptest_schema.rounduptest.
This will take quite a while. Maybe consider a subset of the full
postgresql test suite for use by the schema branch? How to do this?
Maybe use pytest mark pg_schema registered using pytest_configure
to limit the run somehow?
|
msg7924 |
Author: [hidden] (rouilj) |
Date: 2023-12-27 04:02 |
|
This has received a new look due to issue 2551310. 2551310 was the result
of issue 2551299 where the user wanted to use pg_service.conf to specify
the connection parameters including a postgresql schema.
This patch makes Roundup schema aware at least. However how to determine the schema
when using pg_service.conf is undetermined at this time.
|
msg7929 |
Author: [hidden] (rouilj) |
Date: 2023-12-28 20:24 |
|
Committed:
changeset: 7719:3071db43bfb6
Applied version of Stuart's patch. But I broke use of pg_service.conf (issue2551299).
changeset: 7723:8147f6deac9f
Fixed breakage of pg_service.conf done by 3071db43bfb6. Replaced use of db_schema_split
by get_database_schema_names().
Also includes support for schema definition in pg_service.conf.
All postgres tests are run against the schema version as well. Also testing for service file
support has been added.
Docs updated including adding directions for production setup to postgresql.txt and mysql.txt.
pytest pg_schema mark defined and added to the schema test cases. Currently I am running
all tests.
|
|
Date |
User |
Action |
Args |
2023-12-28 20:24:50 | rouilj | set | status: open -> fixed resolution: fixed messages:
+ msg7929 |
2023-12-28 03:15:00 | rouilj | set | priority: normal assignee: rouilj status: new -> open components:
+ Documentation |
2023-12-27 04:02:40 | rouilj | set | messages:
+ msg7924 |
2023-12-27 03:45:02 | rouilj | set | files:
+ schema_2.4.0_baseline.patch messages:
+ msg7923 |
2016-04-09 05:24:23 | rouilj | set | nosy:
+ rouilj messages:
+ msg5511 |
2014-09-15 09:29:49 | ber | set | nosy:
+ ber messages:
+ msg5144 |
2014-09-13 05:15:01 | smcgraw | create | |
|