Обсуждение: pgweb dev install hurdles

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

On Sat, May 19, 2012 at 10:42 PM, Josh Kupershmidt <schmiddy@gmail.com> 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/