Strings handled as numbers on inserts

Description

An element that is declared as a string/varchar, but happens to have a numeric value, is treated as a number, not as a string. This can cause the database to refuse the value and thus the entire feature. The examples below illustrate this:

<OSECTION> w</OSECTION> : accepted, in stdout.log OSECTION= w

But:
<OSECTION> 1</OSECTION> : fails, in stdout.log: OSECTION=1.0
This should have been OSECTION= 1

Environment

None

Activity

Show:
codehaus
April 10, 2015, 4:00 PM

CodeHaus Comment From: jgarnett - Time: Wed, 4 Feb 2004 19:35:10 -0600
---------------------
<p>cholmesny: Uh, ok I just looked at the catalog api and have no idea what that was supposed to explain.

Jody Garnett: The Catalog/FeatureTypeMetaData/AttributeTypeMetaData has everything that FeatureType/AttributeType does not

Jody Garnett: you asked what was needed..

Jody Garnett: At the very least it should have the gml or xs reference there

cholmesny: Ok, I see putMetaData and getMetaData.

Jody Garnett: (I am looking at it now too)

Jody Garnett: Compare and contrast with FeatureTypeInfo/AttributeTypeInfo

cholmesny: And attributeTypeInfo has getAttributeType and getAttributeName

Jody Garnett: AttributeType is a "back pointer" I want to get the reference reversed - so that AttributeType points to AttributeTypeMetaData

cholmesny: Ok, sorry, I still don't see why that's needed for TransactionFeatureHandler.

Jody Garnett: Sorry the AttributeTypeInfo has a delegate DTO object that contains the info we were looking for

Jody Garnett: David needs to make this api public (damm)

Jody Garnett: It contains min/max occurs, millable (all duplicated with AttributeType I think)

Jody Garnett: It also contains type and ref and the other schema stuff

Jody Garnett: sorry type &amp; isComplex

Jody Garnett: This is the part that restricts a Geometry to be a LineString

Jody Garnett: (with the help of GMLUTils)

cholmesny: Yeah, I saw the delegate DTO object...

Jody Garnett: (This is the remove delegates problem I was talking about last time )

Jody Garnett: So this is the information that TransactionFeatureHandler needs inorder to tell in order to parse correctly

cholmesny: Ok, I'll have to look into it more, but I still don't see why that sort of metadata is needed. And I sorta feel that if that metadata is needed it shouldn't be in metadata, it should actually be in the AttributeType.

Jody Garnett: Yes

cholmesny: Though I could be wrong, I need to dig in more.

Jody Garnett: MetaData should be all the additional history and so on of the data

Jody Garnett: The type/isComplex info should be in AttributeType

Jody Garnett: (although I don't think they will let me do that - I am sure people would like AttributeType to reflect the dataStores view of the data)

Jody Garnett: rather than additional user supplied restrictions

cholmesny: What is the type?

cholmesny: There is a getType method in attributeType.

cholmesny: You need it more specific than the class?

Jody Garnett: getType in attributeType gets the FeatureType does it no?

Jody Garnett: getType is the xs:string or gml:LineStringType

Jody Garnett: isComplex flags it as being a defined by an xml fragment

cholmesny: No, it gets the class that can be held by the attributeType.

Jody Garnett: the AttributeTypeConfig class is much clearer

Jody Garnett: ok - we need more detail then the class name

Jody Garnett: Database may say Geometry and the user mean LineString

Jody Garnett: Database may say number and the user may mean 3 digits

cholmesny: Ok. I gotta run, and I gotta think about this more.

cholmesny: But you should bring this all up to geotools, I don't think anyone really knows what work you've been doing.

Jody Garnett: I know

cholmesny: And I think some of it should roll directly into the core parts of geotools.

cholmesny: At the very least it should be thought about by everyone.

Jody Garnett: yes - I have been trying to bring it up at several ircs</p>

codehaus
April 10, 2015, 4:00 PM

CodeHaus Comment From: dzwiers - Time: Tue, 17 Feb 2004 18:05:15 -0600
---------------------
<p>Well, the irc solution no longer works, and this appears to be a geotools problem (my stuff does parse as it is told ...) so closing the issue. Also many of the meta classes are now on the chopping block.</p>

codehaus
April 10, 2015, 4:00 PM

CodeHaus Comment From: cholmes - Time: Fri, 20 Feb 2004 13:41:45 -0600
---------------------
<p>No, this isn't a geotools thing. The reason it's not is because we were forced to fork for TransactionFeatureHandler. Ideally it should be done in geotools, but it's not, so we need to handle it. Eventually we can roll the changes into geotools, but this problem is major enough that we should handle it now. It's more than just strings as numbers, it's also nulls, like if someone wants to do an insert but leaves some blank. This needs to be fixed for 1.2.0 - if you don't want it I'm going to do it after I get locking working. It's fine if it don't work for beta.</p>

codehaus
April 10, 2015, 4:00 PM

CodeHaus Comment From: jgarnett - Time: Mon, 15 Mar 2004 16:10:15 -0600
---------------------
<p>From gt2 irc: (it seems if we pass in a FeatureType life will improve)</p>

<p>You neded clarification from chris - can I help?

groldan I can't figure out if both are related

aaime Basically, why geoserver never passes the attribute type to the ExpressionSaxParser?

groldan since geos-40 talks about WFS specifics

iant could it be using ExpressionDOMParser?

jgarnett Yes it is

groldan ExpressionSaxParser is guessing the literal type

iant I couldn;t think of a better way of doing that

groldan and that's where the confussion starts, since it do not chrashes there, but when the query is executed

iant remember we didn't have feature types in those days

jgarnett This almost brings us back to our first agenda item - expanding FeatureType with recent feedback from GeoSever

groldan I think a possible fix is to have ExpressionSaxParser check the type againsts the FeatureType, since it is recieving it in its constructor

jmacgill we do now, though I think someone commented that the type is often null?

groldan but it isn't actually doing much use of it, and geoserver is passing it a null FeatureType indeed

jmacgill can we stop geoserver doing that?

groldan we can, but need to rework ExpressionSaxParser too, since it is not using it at all

groldan we sould use AttributeType.parse instead of the current try to instantiate an Integer or a Double

IanS sounds about right

groldan (I'm out for a while, my son has a nightmare <img class="emoticon" src="https://jira.codehaus.org/images/icons/emoticons/sad.gif" height="16" width="16" align="absmiddle" alt="" border="0"/>

jgarnett Just an aside, will we always require a FeatureType in order to read GML? We would need to derive a FeatureType from the specified XMLSchema (which we don't currently parse).

jgarnett Translation we can rig up something quick for GeoServer, but other apps may not be so lucky.</p>

codehaus
April 10, 2015, 4:00 PM

CodeHaus Comment From: cholmes - Time: Tue, 6 Apr 2004 09:40:56 -0500
---------------------
<p>Woo hoo! Finally killed this little guy. Please test things out to be sure, but I'm pretty sure this should be fixed, I use the AttributeType's parse method. Had to do a few hacks for insert stuff to get this to work, but overall it's definitely an improvement.</p>

Assignee

Unassigned

Reporter

codehaus

Triage

None

Fix versions

Affects versions

Components

Priority

Medium
Configure