Code

Opened 5 years ago

Closed 5 years ago

Last modified 5 years ago

#11677 closed (wontfix)

PostGIS DB creation SQL not found on Fedora-based installs.

Reported by: alexdutton Owned by: jbronn
Component: GIS Version: 1.1
Severity: Keywords: postgis fedora pg_config
Cc: adamfast@…, alexander.dutton@… Triage Stage: Design decision needed
Has patch: yes Needs documentation: yes
Needs tests: no Patch needs improvement: yes
Easy pickings: UI/UX:

Description

Django looks for lwpostgis.sql and spatial_ref_sys.sql in "pg_config --sharedir", but they are kept in "pg_config --sharedir/contrib" on Fedora systems. Additionally, lwpostgis.sql is renamed lwpostgis-64.sql on 64-bit machines.

The attached patch results in Django looking in more than one place before giving up.

Attachments (1)

postgis-fedora.diff (1.7 KB) - added by alexdutton 5 years ago.
SVN diff of changes to check more than one location for postgis files.

Download all attachments as: .zip

Change History (7)

Changed 5 years ago by alexdutton

SVN diff of changes to check more than one location for postgis files.

comment:1 follow-up: Changed 5 years ago by adamfast

  • Cc adamfast@… added
  • Needs documentation set
  • Needs tests unset
  • Patch needs improvement set
  • Triage Stage changed from Unreviewed to Design decision needed

This is probably best fixed through a bit better documentation explaining that POSTGIS_SQL_PATH is usable in these circumstances.

It discusses it here http://geodjango.org/docs/testing.html?highlight=postgis_sql_path#postgis-sql-path in the context of testing. Are you running tests or doing something else? Either way, that option in your settings file will make it work without any code changes.

The reality is a lot of distros and OSes will keep these files in all sorts of different places, and it's not really appropriate to build up a "database" of sorts on where each of them could be. Default it to something (or even take away the default - and when the setting isn't set complain) but make it easily changeable, which it already is.

comment:2 in reply to: ↑ 1 ; follow-up: Changed 5 years ago by alexdutton

Replying to adamfast:

This is probably best fixed through a bit better documentation explaining that POSTGIS_SQL_PATH is usable in these circumstances.

It discusses it here http://geodjango.org/docs/testing.html?highlight=postgis_sql_path#postgis-sql-path in the context of testing. Are you running tests or doing something else? Either way, that option in your settings file will make it work without any code changes.

Okay; I didn't see that one. It doesn't help in the context of lwpostgis-64.sql though. And yes, I'm running tests.

The reality is a lot of distros and OSes will keep these files in all sorts of different places, and it's not really appropriate to build up a "database" of sorts on where each of them could be. Default it to something (or even take away the default - and when the setting isn't set complain) but make it easily changeable, which it already is.

I'll agree that in retrospect my solution is suboptimal.

Trying to find files that may go AWOL and then passing them to psql has another problem in that it prompts for the database password (which is in the settings module) three times when running tests. The installation instructions for GeoDjango suggest creating a template and then creating the development/production database from there. Would it therefore make sense to create the test database from the same template? There would then be a POSTGIS_TEMPLATE_NAME which would default to 'template_postgis', with documentation to say that the template is expected when running tests. This could be done within psycopg2, removing the need to enter passwords manually.

comment:3 Changed 5 years ago by alexdutton

  • Cc alexander.dutton@… added

comment:4 in reply to: ↑ 2 Changed 5 years ago by jbronn

  • Owner changed from nobody to jbronn

Replying to alexdutton:

Would it therefore make sense to create the test database from the same template? There would then be a POSTGIS_TEMPLATE_NAME which would default to 'template_postgis', with documentation to say that the template is expected when running tests. This could be done within psycopg2, removing the need to enter passwords manually.

This setting already exists, and is POSTGIS_TEMPLATE. Thus set POSTGIS_TEMPLATE='template_postgis' in your settings and the test runner should be fine, even on Fedora.

I'll update the testing docs to instruct users to use a template for testing because (i) its faster and (ii) the release of PostGIS 1.4 changed the file name to postgis.sql anyways. Because the template db is the way to go, I'm -1 on having a db of PostGIS locations because some distro is always going to be missing. I'll keep this ticket open until the docs have changed, but I otherwise do not plan on applying this patch absent a convincing argument to the contrary.

comment:5 Changed 5 years ago by jbronn

  • Resolution set to wontfix
  • Status changed from new to closed

comment:6 Changed 5 years ago by jbronn

Testing docs have been updated with a note recommending use of POSTGIS_TEMPLATE.

Add Comment

Modify Ticket

Change Properties
<Author field>
Action
as closed
as The resolution will be set. Next status will be 'closed'
The resolution will be deleted. Next status will be 'new'
Author


E-mail address and user name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.