public inbox for [email protected]
help / color / mirror / Atom feedpgweb dev install hurdles
2+ messages / 2 participants
[nested] [flat]
* pgweb dev install hurdles
@ 2012-05-19 20:42 Josh Kupershmidt <[email protected]>
2012-05-23 13:26 ` Re: pgweb dev install hurdles Magnus Hagander <[email protected]>
0 siblings, 1 reply; 2+ messages in thread
From: Josh Kupershmidt @ 2012-05-19 20:42 UTC (permalink / raw)
To: pgsql-www
Hi all,
I finally got around to trying out pgweb locally, following the
instructions in dev_install.rst. The first hurdle I hit was due to
DATABASE_NAME not being set in settings_local.py, which results in the
manage.py exception:
"You need to specify NAME in your Django settings file."
Since step 3 of dev_install.rst recommends creating the "pgweb"
database for this application, the suggested overrides for
settings_local.py in step 4 should include a DATABASE_NAME pointing
there.
Next, while trying to load in community_login.sql per step 6 of the
dev_install instructions, I encountered this:
josh@vboxdeb:~/src/pgweb/sql$ psql pgweb -f community_login.sql
BEGIN
CREATE FUNCTION
CREATE FUNCTION
psql:community_login.sql:87: ERROR: relation "users_old" does not exist
LINE 4: ...lower(username)=lower($1) UNION ALL SELECT 1 from users_old ...
I didn't see anywhere the "users_old" relation was defined, other than
a mention in ./tools/migrate/1_crunch_in_sql.sql. I was able to work
around this problem by making a dummy users_old table with the
appropriate columns, but perhaps this table should be included in the
schema?
Then, when I ran load_initial_data.sh, I ran into this:
Problem installing fixture './core/fixtures/data.yaml': Traceback
(most recent call last):
File "/usr/lib/pymodules/python2.6/django/core/management/commands/loaddata.py",
line 172, in handle
obj.save(using=using)
... snip ...
File "/usr/lib/pymodules/python2.6/django/db/backends/postgresql_psycopg2/base.py",
line 44, in execute
return self.cursor.execute(query, args)
IntegrityError: null value in column "firstreldate" violates not-null constraint
DETAIL: Failing row contains (1, 8.4, 0, 2009-07-01,
release-8-4.html, f, t, null, null, null).
which corresponded to this error in my server log:
ERROR: null value in column "firstreldate" violates not-null constraint
DETAIL: Failing row contains (1, 8.4, 0, 2009-07-01,
release-8-4.html, f, t, null, null, null).
STATEMENT: INSERT INTO "core_version" ("id", "tree", "latestminor",
"reldate", "relnotes", "current", "supported", "docsloaded",
"firstreldate", "eoldate") VALUES (1, '8.4', 0, '2009-07-01',
'release-8-4.html', false, true, NULL, NULL, NULL)
I hacked up ./pgweb/core/fixtures/data.yaml to include a
"firstreldate" (copied from "reldate", no idea if that was right) and
"eoldate" until load_initial_data.sh worked OK.
Attached is a patch containing the few fixes/kludges I used to get
pgweb running locally.
Josh
Attachments:
[text/x-patch] dev_install_fixes.diff (3.5K, 2-dev_install_fixes.diff)
download | inline diff:
diff --git a/docs/dev_install.rst b/docs/dev_install.rst
new file mode 100644
index c45582c..8952fc9
*** a/docs/dev_install.rst
--- b/docs/dev_install.rst
*************** So, you're ready to contribute to pgweb,
*** 5,11 ****
local working copy of the website code, so you have something to work
with. Here's a quick step-by-step on how to do that:
! 1. Make sure you have downloaded and installed django *version 1.2*
(or later). You will also need the dependencies *psycopg2*, *yaml*
and *markdown* (these are python libraries, so prefix python- for Debian
packages, for example).
--- 5,11 ----
local working copy of the website code, so you have something to work
with. Here's a quick step-by-step on how to do that:
! #. Make sure you have downloaded and installed django *version 1.2*
(or later). You will also need the dependencies *psycopg2*, *yaml*
and *markdown* (these are python libraries, so prefix python- for Debian
packages, for example).
*************** with. Here's a quick step-by-step on how
*** 28,33 ****
--- 28,34 ----
NO_HTTPS_REDIRECT=True
SESSION_COOKIE_SECURE=False
SESSION_COOKIE_DOMAIN=None
+ DATABASE_NAME="pgweb"
#. In the pgweb directory run the following command to create all
tables and indexes, as well as create a superuser for your local
installation::
diff --git a/pgweb/core/fixtures/data.yaml b/pgweb/core/fixtures/data.yaml
new file mode 100644
index bc8dc5b..36662f0
*** a/pgweb/core/fixtures/data.yaml
--- b/pgweb/core/fixtures/data.yaml
***************
*** 6,11 ****
--- 6,13 ----
"relnotes": "release-8-4.html",
"tree": "8.4",
"reldate": "2009-07-01",
+ "eoldate": "2014-07-01",
+ "firstreldate": "2009-07-01",
"latestminor": 0
}
},
***************
*** 16,21 ****
--- 18,25 ----
"relnotes": "release-8-3-7.html",
"tree": "8.3",
"reldate": "2009-03-17",
+ "eoldate": "2013-02-01",
+ "firstreldate": "2009-03-17",
"latestminor": 7
}
},
***************
*** 25,31 ****
"fields": {
"relnotes": "release-8-2-13.html",
"tree": "8.2",
! "reldate": "2009-03-17",
"latestminor": 13
}
},
--- 29,37 ----
"fields": {
"relnotes": "release-8-2-13.html",
"tree": "8.2",
! "reldate": "2009-03-17",
! "eoldate": "2011-12-01",
! "firstreldate": "2009-03-17",
"latestminor": 13
}
},
***************
*** 36,41 ****
--- 42,49 ----
"relnotes": "release.html#RELEASE-8-1-17",
"tree": "8.1",
"reldate": "2009-03-17",
+ "eoldate" : "2010-11-01",
+ "firstreldate": "2009-03-17",
"latestminor": 17
}
},
***************
*** 46,51 ****
--- 54,61 ----
"relnotes": "release.html#RELEASE-8-0-21",
"tree": "8.0",
"reldate": "2009-03-17",
+ "eoldate": "2010-10-01",
+ "firstreldate": "2009-03-17",
"latestminor": 21
}
},
diff --git a/sql/varnish.sql b/sql/varnish.sql
new file mode 100644
index 3de9196..1b5f8d7
*** a/sql/varnish.sql
--- b/sql/varnish.sql
*************** BEGIN;
*** 2,8 ****
--
-- Create a function to purge from varnish cache
! -- By defalut this adds the object to a pgq queue,
-- but this function can be replaced with a void one
-- when running a development version.
--
--- 2,8 ----
--
-- Create a function to purge from varnish cache
! -- By default this adds the object to a pgq queue,
-- but this function can be replaced with a void one
-- when running a development version.
--
^ permalink raw reply [nested|flat] 2+ messages in thread
* Re: pgweb dev install hurdles
2012-05-19 20:42 pgweb dev install hurdles Josh Kupershmidt <[email protected]>
@ 2012-05-23 13:26 ` Magnus Hagander <[email protected]>
0 siblings, 0 replies; 2+ messages in thread
From: Magnus Hagander @ 2012-05-23 13:26 UTC (permalink / raw)
To: Josh Kupershmidt <[email protected]>; +Cc: pgsql-www
On Sat, May 19, 2012 at 10:42 PM, Josh Kupershmidt <[email protected]> wrote:
> Hi all,
>
> I finally got around to trying out pgweb locally, following the
> instructions in dev_install.rst. The first hurdle I hit was due to
Ah, great. Clearly these instructions haven't been updated along
changes, and were in need of some fixing :-)
> DATABASE_NAME not being set in settings_local.py, which results in the
> manage.py exception:
> "You need to specify NAME in your Django settings file."
>
> Since step 3 of dev_install.rst recommends creating the "pgweb"
> database for this application, the suggested overrides for
> settings_local.py in step 4 should include a DATABASE_NAME pointing
> there.
Yup, correct.
> Next, while trying to load in community_login.sql per step 6 of the
> dev_install instructions, I encountered this:
>
> josh@vboxdeb:~/src/pgweb/sql$ psql pgweb -f community_login.sql
> BEGIN
> CREATE FUNCTION
> CREATE FUNCTION
> psql:community_login.sql:87: ERROR: relation "users_old" does not exist
> LINE 4: ...lower(username)=lower($1) UNION ALL SELECT 1 from users_old ...
>
> I didn't see anywhere the "users_old" relation was defined, other than
> a mention in ./tools/migrate/1_crunch_in_sql.sql. I was able to work
> around this problem by making a dummy users_old table with the
> appropriate columns, but perhaps this table should be included in the
> schema?
Hmm. That's really a part of the migration only and shouldn't be used
on a new system. What would be better would be to redefine the
community_login function not to use it I think. OTOH, in that case it
doesn't really work exactly the same way.
Hmm.
Yeah, i guess creating a dummy table is what will be needed. It won't
ever be re-run on the master after all...
> Then, when I ran load_initial_data.sh, I ran into this:
oh wow. Clearly nobody has run that for a while :-)
> I hacked up ./pgweb/core/fixtures/data.yaml to include a
> "firstreldate" (copied from "reldate", no idea if that was right) and
> "eoldate" until load_initial_data.sh worked OK.
>
> Attached is a patch containing the few fixes/kludges I used to get
> pgweb running locally.
Thanks! Applied, including the changes for the SQL.
--
Magnus Hagander
Me: http://www.hagander.net/
Work: http://www.redpill-linpro.com/
^ permalink raw reply [nested|flat] 2+ messages in thread
end of thread, other threads:[~2012-05-23 13:26 UTC | newest]
Thread overview: 2+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2012-05-19 20:42 pgweb dev install hurdles Josh Kupershmidt <[email protected]>
2012-05-23 13:26 ` Magnus Hagander <[email protected]>
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox