Re: [GUSDEV] bug in GUS schema, evidentiated by InsertSequenceFeatures

[<an...@ne...>]

Quoting Michael Saffitz <m...@sa...>:

> Antonio is correct here-- it looks like the postgres triggers aren't be=
ing
> correctly generated for this table. I had thought I had fixed this, but=
 I
> guess not.  These are in the db writer for postgres within the db admin
> package.  Search for 'ON INSERT TO'.  Antonio-- it may help if you forw=
ard
> along your install logs (that include all SQL used in generating the
> instance).
> Steve's also correct-- bug 177 appears to track a different issue.

I fear that while the database error does appear to be different, the
underlying issue is exactly the same.

Following Steve's advice to try suggesting a fix, I've been digging furth=
er.
If I got your code correctly, all this wreck is generated when the schema
hierarchy gets converted, in

 GUS/DBAdmin/src/java/org/gusdb/dbadmin/util/GusClassHierarchyConverter.j=
ava

In function 'buildSuperClassView', (around line 440 in GUS 3.5; but
'buildSubClassView' exhibits the same issue) the code goes like this:

-------------------------------------------------------------------------=
---
// Housekeeping Columns and complete for the Version View
if (impTable.isVersioned()) {
  superClassView.setVersioned(true);
  verSql =3D sql.concat(" ");

  for (Iterator i =3D verHousekeepingColumns.iterator(); i.hasNext();) {
    Column column =3D (Column)i.next();
    verSql =3D verSql.concat(", " + column.getName());
    superClassView.getVersionView().addColumn(new ColumnPair(column.getNa=
me(),
             column.getName()));
  }
  verSql =3D verSql.concat(
    " FROM " +
    impTable.getVersionTable().getSchema().getName() +
    "." + impTable.getVersionTable().getName() +
    ";");
  superClassView.getVersionView().setSql(verSql);
}
-------------------------------------------------------------------------=
---

Now, the problem is that while 'verSql' is correctly generated (because i=
t
starts with 'sql'), the original view's colums are not copied at all.

The reason is that GusView behaves differently from GusTable, since its
'setVersioned()' method does not copy the base view colums as one might h=
ave
expected after having looked at GusTable.

As far as I can tell this has no relation to the actual database instance=
 in
use, but I'd say that this is the core of the problem.

HTH,

Antonio


----------------------------------------------------------------
Net Wise webmail system - http://www.netwise.it
This message was sent using IMP, the Internet Messaging Program.