public inbox for [email protected]
help / color / mirror / Atom feedFrom: Magnus Hagander <[email protected]>
To: Josh Kupershmidt <[email protected]>
Cc: w^3 <[email protected]>
Subject: Re: pgweb dev install hurdles
Date: Wed, 23 May 2012 15:26:59 +0200
Message-ID: <CABUevEzdwtGF_s4WGWJauVO8YhH8t5SB3rNd1Rd6rK6h85jOtQ@mail.gmail.com> (raw)
In-Reply-To: <CAK3UJRE3QfVzbBCtGJUqOMrXnMMH+=s24OnQC_PUDD7uiH=jYw@mail.gmail.com>
References: <CAK3UJRE3QfVzbBCtGJUqOMrXnMMH+=s24OnQC_PUDD7uiH=jYw@mail.gmail.com>
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/
view thread (2+ messages)
reply
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: [email protected]
Cc: [email protected], [email protected]
Subject: Re: pgweb dev install hurdles
In-Reply-To: <CABUevEzdwtGF_s4WGWJauVO8YhH8t5SB3rNd1Rd6rK6h85jOtQ@mail.gmail.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox