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

[Poliana M. <pol...@gm...>]

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:
> Hey Alberto,
>=20
> Here is what I have so far.  Sorry I don't have the complete solution but
> I don't have any sort of setup yet on a Postgres instance, I will see wha=
t
> I can do about getting that set up on our side for better debugging.
>=20
> 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 m=
akes an update and try to insert characters in that field that was "number(=
12)" then it was only accepting numbers.
>    >
>=20
> The next line you mention (line 123) is
>=20
> String rownumSql =3D "update " + tableName + " set i =3D " + tableName +
> "_sq.nextval";
>=20
> Now that should evaluate to "update query_result_2 set i =3D
> query_result_2_sq.nextval"
>=20
> 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 t=
o
> "query_result_2_sq" as it seems to be in your code...where did the
> ".nextval" go??
>=20
> Can you make sure that line 123 is what I think it should be above?  Sorr=
y
> 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 poin=
t
> and they were all incorporated into 1.1.  (as a side note, we have 1.2 ou=
t
> if you want to work with that instead).
>=20
> Regardless, that column should remain a number, not the string it is
> above.
>=20
> Let us handle the ResultFactory issue after we solve this one because the=
y
> might be related.  I will continute to investigate.
>=20
> Dave
> >
> > 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 shou=
ld 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 lo=
oks like we have lot of debugging to do, if not maybe we are just not invok=
ing/using the commands properly... as usual, any further suggestions are gr=
eatly appreciated ;-)
> >
> > Alberto
> >
> >
>