[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