Re: [Gusdev-gusdev] Problem building WDK on Fedora

[Steve F. <sfi...@pc...>]

Folks-

We at Penn have not tested  the PostgresSQL stuff in the wdk, and are=20
not really set up to do so yet.    you brazilian guys should feel free=20
to play with PostgreSql.java to get things to work.

steve

Poliana Mateus wrote:

>O erro que o Dave menciona....j=E1 foi restaurado no arquivo. Realmente
>deveria receber um n=FAmero....enfim, ele voltou ao original.
>S=F3 alterei de "number(12)" para "numeric(12)".
>
>Abra=E7o,
>Poliana
>
>
>On Fri, 28 Jan 2005 14:01:53 -0500 (EST), Dave Barkan
><db...@pc...> wrote:
> =20
>
>>Hey Alberto,
>>
>>Here is what I have so far.  Sorry I don't have the complete solution b=
ut
>>I don't have any sort of setup yet on a Postgres instance, I will see w=
hat
>>I can do about getting that set up on our side for better debugging.
>>
>>First of all, your assertion here:
>>
>>   =20
>>
>>>In the "PostgreSQL.java" file we edited:
>>>
>>>line 117:
>>>String alterSql =3D "alter table " + tableName + " add i varchar(100)"=
;
>>>
>>>We changed "number(12)" to "varchar(100)" because in the next line it =
makes an update and try to insert characters in that field that was "numb=
er(12)" then it was only accepting numbers.
>>>     =20
>>>
>>   >
>>
>>The next line you mention (line 123) is
>>
>>String rownumSql =3D "update " + tableName + " set i =3D " + tableName =
+
>>"_sq.nextval";
>>
>>Now that should evaluate to "update query_result_2 set i =3D
>>query_result_2_sq.nextval"
>>
>>and query_result_2_sq.nextval is the proper way to call the next value
>>in the primary key sequence for that table, right?  So that should
>>evaluate to a number, not a string.  I am not sure why it is evaluating=
 to
>>"query_result_2_sq" as it seems to be in your code...where did the
>>".nextval" go??
>>
>>Can you make sure that line 123 is what I think it should be above?  So=
rry
>>to be obtuse about this, but just make sure you are using WDK version 1=
.1
>>or later for this, I remember we made some PostGres upgrades at some po=
int
>>and they were all incorporated into 1.1.  (as a side note, we have 1.2 =
out
>>if you want to work with that instead).
>>
>>Regardless, that column should remain a number, not the string it is
>>above.
>>
>>Let us handle the ResultFactory issue after we solve this one because t=
hey
>>might be related.  I will continute to investigate.
>>
>>Dave
>>   =20
>>
>>>In "ResultFactory.java", lines 312 until 346:
>>>
>>>In the following error, it assumes the "nextID" variable as being
>>>"gus.QueryInstance_pkseq" and returns the error because this field sho=
uld receive a numeric value: we changed the variable to a numeric value (=
in the script) to test and the data were inserted with success.
>>>
>>>[poliana@phytomonas gus_home]$ wdkQuery -model toyModel -query
>>>RnaIds.ByDbESTLib -params NumEstLibs 6 AssemblyConsistency 80
>>>Failed executing sql:
>>>insert into gus.QueryInstance (query_instance_id, query_name, cached,
>>>session_id, dataset_name, start_time, param0, param1) values
>>>(gus.QueryInstance_pkseq, 'RnaIds.ByDbESTLib', 1, null, null, now(),
>>>'6', '80')
>>>
>>>org.gusdb.wdk.model.WdkModelException:
>>>org.postgresql.util.PSQLException: ERROR: relation "gus" does not
>>>exist
>>>     =20
>>>
>>>----------------------------------------------------------------------=
-------------------------------------
>>>After debugging that, we got this:
>>>
>>>[poliana@phytomonas gus_home]$ wdkQuery -model toyModel -query
>>>RnaIds.ByDbESTLib -params NumEstLibs 6 AssemblyConsistency 80
>>>92484435         query_result_2_sq
>>>92484471         query_result_2_sq
>>>92484523         query_result_2_sq
>>>92484578         query_result_2_sq
>>>92484601         query_result_2_sq
>>>92484678         query_result_2_sq
>>>92484682         query_result_2_sq
>>>92484686         query_result_2_sq
>>>92484695         query_result_2_sq
>>>92484703         query_result_2_sq
>>>92484708         query_result_2_sq
>>>92484710         query_result_2_sq
>>>92484731         query_result_2_sq
>>>92484741         query_result_2_sq
>>>92484752         query_result_2_sq
>>>92484755         query_result_2_sq
>>>92484758         query_result_2_sq
>>>92484764         query_result_2_sq
>>>92484767         query_result_2_sq
>>>92484768         query_result_2_sq
>>>92484772         query_result_2_sq
>>>92484779         query_result_2_sq
>>>92484780         query_result_2_sq
>>>92484801         query_result_2_sq
>>>92484835         query_result_2_sq
>>>92484836         query_result_2_sq
>>>101853404        query_result_2_sq
>>>
>>>So... is the latter the expected output for "wdkQuery" ? If so, then l=
ooks like we have lot of debugging to do, if not maybe we are just not in=
voking/using the commands properly... as usual, any further suggestions a=
re greatly appreciated ;-)
>>>
>>>Alberto
>>>
>>>
>>>     =20
>>>