[Dachs-support] [itteam] gavo import lock
Markus Demleitner
msdemlei at ari.uni-heidelberg.de
Sat Nov 5 13:24:58 CET 2016
Hi Carlos,
On Fri, Nov 04, 2016 at 01:11:03PM -0200, carlosadean at linea.gov.br wrote:
> Hi Markus,
>
> I used the 'gavo purge' but a new error message was introduced.
>
> [gavo at devel2 inputs [master]]$ gavo upgrade
> > Adding column_index column to TAP_SCHEMA.columns... *X*X* Uncaught exception at toplevel
> *** Error: Oops. Unhandled exception ProgrammingError.
>
> Exception payload: column "column_index" of relation "columns" already
> exists
Ah, the joys of schema changes. Out of curiosity, what does
gavo --version
output here? Clearly, this shouldn't happen; technically, DaCHS does
the upgrade to each schema version in a transaction of its own, so if
it has created the column_index, the DB should be at (at least) schema
version 14, and it shouldn't try to re-create it.
I'd be curious how the addition of the table column escaped the
transaction (if that's what's happening), and perhaps gavo
--version's output can help me there.
But on to your problem:
> ** WARNING: RD cluster/mag_auto_10023232_i couldn't be loaded (Element with id u'tilename' could not be located in parse context). Fix and run gavo imp -m on it to get column indices in TAP_SCHEMA
> *X*X* Uncaught exception at toplevel
> *** Error: Oops. Unhandled exception UnboundLocalError.
>
> Exception payload: local variable 'rd' referenced before assignment
>
> Definitively I do not know how can I fix this, any suggestion?
That's a bug on my end, and I should update the package. I won't get
around to doing this before Monday. The following patch should fix it:
===================================================================
--- gavo/user/upgrade.py (revision 5377)
+++ gavo/user/upgrade.py (working copy)
@@ -397,6 +397,7 @@
base.ui.notifyWarning("RD %s couldn't be loaded (%s)."
" Fix and run gavo imp -m on it to get"
" column indices in TAP_SCHEMA"%(rdId, msg))
+ continue
rsc.makeData(dd, forceSource=rd, connection=connection)
-- but it's better and faster to fix the problem that triggered that
bug (which I hadn't noticed since on the boxes I ran the upgrade on
all RDs were ok. Doing proper tests for the upgrade steps is
beastly and thankless).
Anyway, the root of the problem is that, as the DaCHS' message said
(albeit somewhat hidden), the RD cluster/mag_auto_10023232_i is bad --
there's something like original="tilename" or buildFrom="tilename" in
it, and that reference cannot be resolved, and so the RD cannot be
used. DaCHS should have ignored it, but the missing continue
(see the patch) prevented that.
Anyway -- if you remove the reference, at least *this* step should work.
To avoid further surprises, just run
gavo val ALL
-- this makes DaCHS validate all RDs within inputs -- and fix all
errors (warnings are not a problem in this context).
Pro tip: Run
gavo val -c ALL
now and then -- this makes sure that DaCHS' idea of how your tables
look like matches what they actually are in the database.
Cheers (and sorry 'bout that upgrade trouble),
Markus
More information about the Dachs-support
mailing list