[Dachs-support] ProgrammingError Can't adapt (was: gavo import lock)
carlosadean at linea.gov.br
carlosadean at linea.gov.br
Mon Nov 14 14:49:54 CET 2016
Hello Markus,
Good news!!!
>
> Ok, so there's a different problem. I take the liberty of changing
> the Subject.
>
>
> This message is very weird indeed. It is coming from psycopg2, the
> Postgresql interface used by DaCHS. It essentially says that there
> was an instance of the datatype in the record prepared by DaCHS that
> psycopg2 doesn't know how to push into postgres (i.e., something
> you've mapped it).
>
> However, after "can't adapt" there should be the repr() of that "odd"
> thing. Since there's nothing there, it's something that either has
> and empty repr() or raised an exception while generating a repr().
>
> I'd have to see txt/q to make an educated guess what it might be; if
> you can't send it over the public list, feel free to send it (or at
> least the relevant rowmaker) to gavo at ari.uni-heidelberg.de.
>
-- Ops! I just used the old (gavo doc) example to test that import.
However, from the current gavo documentation I created a new RD example and finally the import worked (arihip)!
[gavo at devel2 inputs [master]]$ gavo --hints imp -v arihip/q
Making data import
Starting /opt/dachs/inputs/arihip/data/data.txt.gz
Shipped 5000/5000
[...]
Shipped 5000/90000
Done /opt/dachs/inputs/arihip/data/data.txt.gz, read 90842
Shipped 842/90842
Create index Primary key on arihip.main
Create index main_mv
Create index main_q3c_main
Rows affected: 90842
[gavo at devel2 inputs [master]]$ gavo info arihip/q.rd#main
col min avg max hasnulls
hipno 1 58985.163756852557 120404 False
srcSel F61 - T2H False
raj2000 0.000900008333333 180.914392216 359.979456258 False
dej2000 -89.7824278694 -2.18665815542 89.5694284 False
pmra -0.000904975 -3.06561421824e-07 0.0018797 False
[...]
-- Also, I could import a sample fits creating a RD from scratch (with booster). In any case the txt/q is attached.
I'm investigating why some old RDs are not working yet...
[gavo at devel2 inputs [master]]$ gavo --hints imp -v sample/s.rd
Making data import_table
cc -Wall -DINPUT_LINE_MAX=4000 -DQUERY_N_PARS=4 -DAUTO_NULL='nan' -g -I /usr/include/cfitsio -o booster boosterskel.c func.c -lcfitsio -lm
boosterskel.c: In function 'parseBigint':
boosterskel.c:262: warning: format '%Ld' expects type 'long long int *', but argument 3 has type 'int64_t *'
00130734 records done.
Rows affected: 0
[gavo at devel2 inputs [master]]$ gavo info sample/s.rd#fits
col min avg max hasnulls
TILENAME None - None True
COADD_OBJECTS_ID 2924578917 2939047193.20150076 2971359845 False
DEC -44.967523 -11.9905481177 2.86706 False
RA 6.45317 56.2803576701 151.265903 False
> That's a relatively straightforward and unrelated one. There are two
> different commands for dropping things in DaCHS:
>
> (a) gavo drop <rd> [<ddids>] (potentially with a -f) -- this is
> essentially the reverse of imp; where gavo imp executes the data
> recipes, gavo drop removes the tables built by them; you can pass
> data ids to restrict dropping to certain dd-ids. This is what you'd
> have to do here:
>
> gavo drop txt/q
>
> (b) gavo purge <tablename> -- this just removes tables, both from
> postgres and DaCHS' metadata collections (e.g., TAP_SCHEMA and
> friends). You want that if the RD is gone or doesn't describe the
> table any more. It's a sledge hammer that completely ignores RDs.
> Hence, <tablename> is a SQL table name, like lmc.objects or something
> like that.
>
> I admit that it'd be preferable if the two things could somehow be
> sensibly merged into one. But then functionality is so different
> that such a merge would incur quite a bit of magic, and I'd rather
> not add more of that unless I have to.
>
> We'll have to improve the manpage, though.
>
Thank you for the explanation.
Many thanks for the help!
cheers,
--
Carlos Adean
IT Team
www.linea.gov.br
-------------- next part --------------
A non-text attachment was scrubbed...
Name: txt.tgz
Type: application/x-compressed-tar
Size: 2370 bytes
Desc: not available
URL: <http://lists.g-vo.org/pipermail/dachs-support/attachments/20161114/f86633da/attachment-0002.bin>
More information about the Dachs-support
mailing list