GeoTools

app-schema feature chaining requests nonexistent properties

Details

  • Type: Bug Bug
  • Status: Closed Closed
  • Priority: Major Major
  • Resolution: Cannot Reproduce
  • Affects Version/s: None
  • Fix Version/s: None
  • Component/s: app-schema plugin
  • Labels:
    None

Description

-------- Original Message --------
Subject: [Geoserver-users] App schema feature chaining issue
Date: Wed, 3 Nov 2010 05:46:22 +0800
From: Ryan Zoerb
To: geoserver-users@lists.sourceforge.net

Hi everyone. I'm trying to get application schema with feature chaining working, but I'm running into an issue. I've attached the two mapping files I'm using. WaterWell is the top level element, which can have several nested logElement's. I've been able to successfully get GeoServer to return a correct response without feature chaining, but when I added the chaining, I get this Oracle error: 'ORA-00904: "TIMES": invalid identifier'. Here's the query that GeoServer is doing that returns the error:

SELECT GW_LEV_PK,AGENCY_CD,SITE_NO,DATES,VALUE,REMARK,REMARK_DS,SOURCE_CD,METHOD_CD,METHOD_DS,QW_ACCURACY,QW_ACCURACY_NM,HOST,DBNUM,DWH_INSERT,LEV_CN,LEV_CR,LEV_MN,LEV_MD,MP_LEV_VA,SL_LEV_VA,LEV_ENT_CD,LEV_STATISTICS_CD,LEV_STATISTICS_NM,DATE_ACY_CD,SL_DATUM_CD,LEV_PARTY_TX,LEV_WEB_CD,LEV_AGENCY_CD,LEV_MPNT_SEQ_NU,LEV_RMK_TX,LEV_EQPID_TX,DWH_SITE_ID,PARAMETER_CODE,SOURCE,VALUE_ALL,AGENCY_CD,SITE_NO,DATES,VALUE,STATUS_CD,STATUS_DS,SOURCE_CD,METHOD_CD,METHOD_DS,QW_ACCURACY,QW_ACCURACY_NM,HOST,DBNUM,DWH_INSERT,LEV_CN,LEV_CR,LEV_MN,LEV_MD,TIMES,MP_LEV_VA,SL_LEV_VA,LEV_ENT_CD,LEV_STATISTICS_CD,LEV_STATISTICS_NM,DATE_ACY_CD,SL_DATUM_CD,LEV_PARTY_TX,LEV_WEB_CD,LEV_AGENCY_CD,LEV_MPNT_SEQ_NU,LEV_RMK_TX,LEV_EQPID_TX,DWH_SITE_ID FROM GWSI_LEVELS WHERE SITE_NO = ?

The problem is that the GWSI_LEVELS table doesn't have a column called TIMES. All of the other columns are correct (even though most of them are in that list twice). The pattern I see is that the primary key, GW_LEV_PK, is first in the list, then all of the columns are listed in the same order they are in the db (except for GW_LEV_PK). Then, all the columns except the last three are listed again, but TIMES is put in GW_LEV_PK's column position. Can anyone see what could be causing this, or is it a bug?

Thanks for any help,
Ryan

  1. XML File
    gsml_MappedInterval.xml
    08/Nov/10 2:48 PM
    3 kB
    Ben Caradoc-Davies
  2. XML File
    gwml_WaterWell.xml
    08/Nov/10 2:48 PM
    5 kB
    Ben Caradoc-Davies

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
Ben Caradoc-Davies added a comment -
Attached mapping files attached to Ryan's original email.
Show
Ben Caradoc-Davies added a comment - Attached mapping files attached to Ryan's original email.
Ben Caradoc-Davies made changes -
Field Original Value New Value
Attachment gsml_MappedInterval.xml [ 52092 ]
Attachment gwml_WaterWell.xml [ 52093 ]
Hide
Permalink
Ben Caradoc-Davies added a comment -
-------- Original Message --------
Subject: Re: [Geoserver-users] App schema feature chaining issue
Date: Wed, 3 Nov 2010 23:09:32 +0800
From: Ryan Zoerb
To: Caradoc-Davies, Ben (CESRE, Kensington)
CC: geoserver-users@lists.sourceforge.net

Thanks for the response Ben. GWSI_LEVELS is a table. Here is the output from DESCRIBE GWSI_LEVELS:

DESCRIBE GW_DATA_PORTAL.GWSI_LEVELS
Name Null Type
------------------------------ -------- ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
AGENCY_CD NOT NULL VARCHAR2(5)
SITE_NO NOT NULL VARCHAR2(15)
DATES DATE
VALUE NUMBER
REMARK VARCHAR2(5)
REMARK_DS VARCHAR2(255)
SOURCE_CD VARCHAR2(5)
METHOD_CD VARCHAR2(5)
METHOD_DS VARCHAR2(255)
QW_ACCURACY VARCHAR2(5)
QW_ACCURACY_NM VARCHAR2(255)
HOST NOT NULL VARCHAR2(30)
DBNUM NOT NULL VARCHAR2(2)
DWH_INSERT DATE
LEV_CN VARCHAR2(8)
LEV_CR DATE
LEV_MN VARCHAR2(8)
LEV_MD NOT NULL DATE
GW_LEV_PK NOT NULL NUMBER
MP_LEV_VA VARCHAR2(7)
SL_LEV_VA VARCHAR2(8)
LEV_ENT_CD VARCHAR2(1)
LEV_STATISTICS_CD VARCHAR2(1)
LEV_STATISTICS_NM VARCHAR2(255)
DATE_ACY_CD VARCHAR2(1)
SL_DATUM_CD VARCHAR2(10)
LEV_PARTY_TX VARCHAR2(6)
LEV_WEB_CD VARCHAR2(1)
LEV_AGENCY_CD VARCHAR2(5)
LEV_MPNT_SEQ_NU NUMBER
LEV_RMK_TX VARCHAR2(256)
LEV_EQPID_TX VARCHAR2(20)
DWH_SITE_ID NOT NULL NUMBER
PARAMETER_CODE CHAR(5)
SOURCE VARCHAR2(10)
VALUE_ALL NUMBER


Thanks,
Ryan

On Nov 2, 2010, at 8:20 PM, Ben Caradoc-Davies wrote:

> Ryan,
>
> I do not think this is an app-schema problem as it is the inner feature type that is affected and this error will likely occur before any chaining takes place. My guess is this is either a subtle bug in the geotools oracle support, or an unintended interaction with your database configuration. I cannot find any hardcoded identifier "TIMES" in the code base.
>
> (1) Is GWSI_LEVELS a table, view, or materialized view?
>
> (2) What is the output of "DESCRIBE GWSI_LEVELS"?
>
> Kind regards,
> Ben.
>
Show
Ben Caradoc-Davies added a comment - -------- Original Message -------- Subject: Re: [Geoserver-users] App schema feature chaining issue Date: Wed, 3 Nov 2010 23:09:32 +0800 From: Ryan Zoerb To: Caradoc-Davies, Ben (CESRE, Kensington) CC: geoserver-users@lists.sourceforge.net Thanks for the response Ben. GWSI_LEVELS is a table. Here is the output from DESCRIBE GWSI_LEVELS: DESCRIBE GW_DATA_PORTAL.GWSI_LEVELS Name Null Type ------------------------------ -------- --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- AGENCY_CD NOT NULL VARCHAR2(5) SITE_NO NOT NULL VARCHAR2(15) DATES DATE VALUE NUMBER REMARK VARCHAR2(5) REMARK_DS VARCHAR2(255) SOURCE_CD VARCHAR2(5) METHOD_CD VARCHAR2(5) METHOD_DS VARCHAR2(255) QW_ACCURACY VARCHAR2(5) QW_ACCURACY_NM VARCHAR2(255) HOST NOT NULL VARCHAR2(30) DBNUM NOT NULL VARCHAR2(2) DWH_INSERT DATE LEV_CN VARCHAR2(8) LEV_CR DATE LEV_MN VARCHAR2(8) LEV_MD NOT NULL DATE GW_LEV_PK NOT NULL NUMBER MP_LEV_VA VARCHAR2(7) SL_LEV_VA VARCHAR2(8) LEV_ENT_CD VARCHAR2(1) LEV_STATISTICS_CD VARCHAR2(1) LEV_STATISTICS_NM VARCHAR2(255) DATE_ACY_CD VARCHAR2(1) SL_DATUM_CD VARCHAR2(10) LEV_PARTY_TX VARCHAR2(6) LEV_WEB_CD VARCHAR2(1) LEV_AGENCY_CD VARCHAR2(5) LEV_MPNT_SEQ_NU NUMBER LEV_RMK_TX VARCHAR2(256) LEV_EQPID_TX VARCHAR2(20) DWH_SITE_ID NOT NULL NUMBER PARAMETER_CODE CHAR(5) SOURCE VARCHAR2(10) VALUE_ALL NUMBER Thanks, Ryan On Nov 2, 2010, at 8:20 PM, Ben Caradoc-Davies wrote: > Ryan, > > I do not think this is an app-schema problem as it is the inner feature type that is affected and this error will likely occur before any chaining takes place. My guess is this is either a subtle bug in the geotools oracle support, or an unintended interaction with your database configuration. I cannot find any hardcoded identifier "TIMES" in the code base. > > (1) Is GWSI_LEVELS a table, view, or materialized view? > > (2) What is the output of "DESCRIBE GWSI_LEVELS"? > > Kind regards, > Ben. >
Hide
Permalink
Ben Caradoc-Davies added a comment - - edited
-------- Original Message --------
Subject: Re: [ExternalEmail] Re: [Geoserver-users] App schema feature chaining issue
Date: Fri, 5 Nov 2010 22:25:58 +0800
From: Ryan Zoerb
To: Caradoc-Davies, Ben (CESRE, Kensington)
CC: geoserver-users@lists.sourceforge.net

Sorry for the delay. Yes, publishing GWSI_LEVELS as a WFS simple feature works.

Thanks,
Ryan

On Nov 4, 2010, at 8:46 PM, Ben Caradoc-Davies wrote:

> Ryan,
>
> please publish GWSI_LEVELS as a WFS simple feature. What SQL do you see in the logs when you query it?
>
> If you see the invalid column only when using app-schema, it must be an app-schema bug.
>
> Kind regards,
> Ben.
>
> On 04/11/10 18:44, Andrea Aime wrote:
>> On Thu, Nov 4, 2010 at 8:58 AM, Ben Caradoc-Davies
>> wrote:
>>> Andrea,
>>>
>>> this one has me stumped. Can you think why GeoTools might add a nonexistent
>>> TIMES column when building a prepared statement for Oracle?
>>
>> None. I'm not aware of any part of the code picking up attribute names
>> out of thin
>> air, nor I've ever seen a similar report.
>> There is a simple test to be made: if publishing those oracle tables as simple
>> features work there is probably something going on inside app-schema that adds
>> the non existing attribute in the Query property list (which I believe
>> we don't check
>> for validity).
>>
>> Cheers
>> Andrea
Show
Ben Caradoc-Davies added a comment - - edited -------- Original Message -------- Subject: Re: [ExternalEmail] Re: [Geoserver-users] App schema feature chaining issue Date: Fri, 5 Nov 2010 22:25:58 +0800 From: Ryan Zoerb To: Caradoc-Davies, Ben (CESRE, Kensington) CC: geoserver-users@lists.sourceforge.net Sorry for the delay. Yes, publishing GWSI_LEVELS as a WFS simple feature works. Thanks, Ryan On Nov 4, 2010, at 8:46 PM, Ben Caradoc-Davies wrote: > Ryan, > > please publish GWSI_LEVELS as a WFS simple feature. What SQL do you see in the logs when you query it? > > If you see the invalid column only when using app-schema, it must be an app-schema bug. > > Kind regards, > Ben. > > On 04/11/10 18:44, Andrea Aime wrote: >> On Thu, Nov 4, 2010 at 8:58 AM, Ben Caradoc-Davies >> wrote: >>> Andrea, >>> >>> this one has me stumped. Can you think why GeoTools might add a nonexistent >>> TIMES column when building a prepared statement for Oracle? >> >> None. I'm not aware of any part of the code picking up attribute names >> out of thin >> air, nor I've ever seen a similar report. >> There is a simple test to be made: if publishing those oracle tables as simple >> features work there is probably something going on inside app-schema that adds >> the non existing attribute in the Query property list (which I believe >> we don't check >> for validity). >> >> Cheers >> Andrea
Rini Angreani made changes -
Assignee Rini Angreani [ rini ] Victor Tey [ victortey ]
Hide
Permalink
Victor Tey added a comment - - edited
I was unable to replicate this problem. The data and mapping can be found in http://jira.codehaus.org/browse/GEOT-1276

This is my output from

http://localhost:8080/geoserver/wfs?request=GetFeature&typeName=gwml:WaterWell&maxFeatures=10.


<?xml version="1.0" encoding="UTF-8"?>
<wfs:FeatureCollection numberOfFeatures="1" timeStamp="2010-11-10T13:02:12.282+08:00"
xsi:schemaLocation="http://www.nrcan.gc.ca/xml/gwml/1 http://www.nrcan.gc.ca/xml/gwml/1/gwml.xsd http://www.opengis.net/wfs http://schemas.opengis.net/wfs/1.1.0/wfs.xsd"
xmlns:ogc="http://www.opengis.net/ogc" xmlns:gwml="http://www.nrcan.gc.ca/xml/gwml/1"
xmlns:sa="http://www.opengis.net/sampling/1.0" xmlns:wfs="http://www.opengis.net/wfs"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:gsml="urn:cgi:xmlns:CGI:GeoSciML:2.0"
xmlns:ows="http://www.opengis.net/ows" xmlns:gml="http://www.opengis.net/gml"
xmlns:xlink="http://www.w3.org/1999/xlink">
<gml:featureMembers>
<gwml:WaterWell gml:id="395322075015401">
<sa:sampledFeature>
<null:Observation gml:id="GWSI_LEVELS.fid--81a0ffe_12c342927cf_-7fea">
<null:result/></null:Observation>
</sa:sampledFeature><sa:sampledFeature>
<null:Observation gml:id="GWSI_LEVELS.fid--81a0ffe_12c342927cf_-7fe9">
<null:result/></null:Observation>
</sa:sampledFeature><sa:sampledFeature>
<null:Observation gml:id="GWSI_LEVELS.fid--81a0ffe_12c342927cf_-7fe8">
<null:result/></null:Observation>
</sa:sampledFeature><sa:sampledFeature>
<null:Observation gml:id="GWSI_LEVELS.fid--81a0ffe_12c342927cf_-7fe7">
<null:result/></null:Observation>
</sa:sampledFeature><sa:sampledFeature>
<null:Observation gml:id="GWSI_LEVELS.fid--81a0ffe_12c342927cf_-7fe6">
<null:result/></null:Observation>
</sa:sampledFeature><sa:sampledFeature>
<null:Observation gml:id="GWSI_LEVELS.fid--81a0ffe_12c342927cf_-7fe5">
<null:result/></null:Observation>
</sa:sampledFeature>
<gwml:referenceElevation uom="urn:ogc:def:uom:UCUM:ft_i">65.0</gwml:referenceElevation>
</gwml:WaterWell>
</gml:featureMembers></wfs:FeatureCollection>
Show
Victor Tey added a comment - - edited I was unable to replicate this problem. The data and mapping can be found in http://jira.codehaus.org/browse/GEOT-1276 This is my output from http://localhost:8080/geoserver/wfs?request=GetFeature&typeName=gwml:WaterWell&maxFeatures=10 . <?xml version="1.0" encoding="UTF-8"?> <wfs:FeatureCollection numberOfFeatures="1" timeStamp="2010-11-10T13:02:12.282+08:00" xsi:schemaLocation=" http://www.nrcan.gc.ca/xml/gwml/1 http://www.nrcan.gc.ca/xml/gwml/1/gwml.xsd http://www.opengis.net/wfs http://schemas.opengis.net/wfs/1.1.0/wfs.xsd " xmlns:ogc=" http://www.opengis.net/ogc " xmlns:gwml=" http://www.nrcan.gc.ca/xml/gwml/1 " xmlns:sa=" http://www.opengis.net/sampling/1.0 " xmlns:wfs=" http://www.opengis.net/wfs " xmlns:xsi=" http://www.w3.org/2001/XMLSchema-instance " xmlns:gsml="urn:cgi:xmlns:CGI:GeoSciML:2.0" xmlns:ows=" http://www.opengis.net/ows " xmlns:gml=" http://www.opengis.net/gml " xmlns:xlink=" http://www.w3.org/1999/xlink "> <gml:featureMembers> <gwml:WaterWell gml:id="395322075015401"> <sa:sampledFeature> <null:Observation gml:id="GWSI_LEVELS.fid--81a0ffe_12c342927cf_-7fea"> <null:result/></null:Observation> </sa:sampledFeature><sa:sampledFeature> <null:Observation gml:id="GWSI_LEVELS.fid--81a0ffe_12c342927cf_-7fe9"> <null:result/></null:Observation> </sa:sampledFeature><sa:sampledFeature> <null:Observation gml:id="GWSI_LEVELS.fid--81a0ffe_12c342927cf_-7fe8"> <null:result/></null:Observation> </sa:sampledFeature><sa:sampledFeature> <null:Observation gml:id="GWSI_LEVELS.fid--81a0ffe_12c342927cf_-7fe7"> <null:result/></null:Observation> </sa:sampledFeature><sa:sampledFeature> <null:Observation gml:id="GWSI_LEVELS.fid--81a0ffe_12c342927cf_-7fe6"> <null:result/></null:Observation> </sa:sampledFeature><sa:sampledFeature> <null:Observation gml:id="GWSI_LEVELS.fid--81a0ffe_12c342927cf_-7fe5"> <null:result/></null:Observation> </sa:sampledFeature> <gwml:referenceElevation uom="urn:ogc:def:uom:UCUM:ft_i">65.0</gwml:referenceElevation> </gwml:WaterWell> </gml:featureMembers></wfs:FeatureCollection>
Hide
Permalink
Victor Tey added a comment -
Hi Ryan, would you be able to list the content in your USER_SDO_GEOM_METADATA table?. Rini suggested that it might be something to do with reprojection in your srs. Its another shot in the dark but might be worthwhile investigating this path :)
Show
Victor Tey added a comment - Hi Ryan, would you be able to list the content in your USER_SDO_GEOM_METADATA table?. Rini suggested that it might be something to do with reprojection in your srs. Its another shot in the dark but might be worthwhile investigating this path :)
Hide
Permalink
Ben Caradoc-Davies added a comment -
Ryan Z is not a watcher. Victor, please email him your question. (Even better, ask him to watch this issue.)
Show
Ben Caradoc-Davies added a comment - Ryan Z is not a watcher. Victor, please email him your question. (Even better, ask him to watch this issue.)
Hide
Permalink
Victor Tey added a comment -
I have emailed him already :)
Show
Victor Tey added a comment - I have emailed him already :)
Hide
Permalink
Ben Caradoc-Davies added a comment -
Great! (I often paste emails [with addresses removed] into Jira issues to make this even more obvious.)
Show
Ben Caradoc-Davies added a comment - Great! (I often paste emails [with addresses removed] into Jira issues to make this even more obvious.)
Hide
Permalink
Victor Tey added a comment -
No reply from ryan and i was unable to reproduce the same error with the data he had provided therefore I am closing this issue
Show
Victor Tey added a comment - No reply from ryan and i was unable to reproduce the same error with the data he had provided therefore I am closing this issue
Victor Tey made changes -
Status Open [ 1 ] Resolved [ 5 ]
Resolution Cannot Reproduce [ 5 ]
Hide
Permalink
Andrea Aime added a comment -
Mass closing all issues in resolved state that have not been reopened nor commented over in the last month
Show
Andrea Aime added a comment - Mass closing all issues in resolved state that have not been reopened nor commented over in the last month
Andrea Aime made changes -
Status Resolved [ 5 ] Closed [ 6 ]

People

  • Assignee:
    Victor Tey
    Reporter:
    Ben Caradoc-Davies
Vote (0)
Watch (2)

Dates

  • Created:
    Updated:
    Resolved: