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
<OSECTION> 1</OSECTION> : fails, in stdout.log: OSECTION=1.0
This should have been OSECTION= 1
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 & 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 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 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 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 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>