OK - I'm cool about this, just a bug in the implementation not handling nulls -
even though its possible that nulls should never be used, the implementation is still happy to get the value from the expression, so it should be expected to behave better I think. - I've submitted the patch. Rob Justin Deoliveira wrote: > Hi David, > > As the developer I assume you are referring to the datastore developer? > The "extraData" parameter is something that is more intended to be used > internally by the filter encoder. As the data store developer you will > likely never be just encoding a literal in isolation ( i could be wrong > ), but as part of a binary expression as stated below. Internally the > encoder will pass information around via "extraData". In this case in > the accept(PropertyName) method, the encoder will figure out what the > type of "NAME" is, and pass that to accept(Literal) via extraData. > > -Justin > > David Adler wrote: > >> I ran into the same problem when handling a geometry literal. How is a >> developer supposed to know that the call to accept needs to include an >> extraData parameter of Geometry.class in this case? >> >> Farber, Saul (ENV) wrote: >> >>> Rob, >>> >>> Yeah, cory's right. The 'extraData' object in the FilterVisitor interface >>> is a 'utility' object. Often when passing things around a filter visitor, >>> you want to pass along something else. An output stream to write output >>> to, some 'class context', or a stateful tracker of some sort. >>> >>> In the specific case of the FilterToSQL class, in *most* cases the >>> extraData object is null. However, in the very specific case of resolving >>> a Literal, the parent operator (the one that's 'doing the comparison' as it >>> were) needs to tell the Literal exactly how it's going to be interpreted. >>> >>> For example: >>> >>> <PropertyIsEqualTo> >>> <PropertyName>NAME</PropertyName> >>> <Literal>123</Literal> >>> </PropertyIsEqualTo> >>> >>> Should the comparison function treat 123 as a number or as a string? Well, >>> what are we comparing it to? >>> >>> The FilterToSQL class, when encountering this bit of filter, first visit >>> the PropertyIsEqualTo node, notes that one or the other of the children is >>> a Literal, and then decides that it must tell the code that's encoding the >>> literal how the literal will be expected to behave (as a number or string). >>> So it figures the class of the referenced property (NAME in this case) by >>> doing some FeatureType manipulation, and then passes that class to the >>> visit() method which goes to visit the literal. >>> >>> >>> Sorry if that explanation was overkill. >>> >>> You asked "is there some general documentation about the extradata >>> parameter in the FilterVisitor interface?" >>> >>> The reason there's isn't much that's useful is that it's a pretty general >>> mechanism, that's meant to be abused by whichever particular algorithm >>> decides to implement FilterVisitor. >>> >>> --saul >>> >>> >>> -----Original Message----- >>> From: [EMAIL PROTECTED] on behalf of Cory Horner >>> Sent: Thu 4/5/2007 11:20 AM >>> To: geotools list >>> Cc: Rob Atkinson >>> Subject: Re: [Geotools-devel] Implementing GeoAPI FilterVisitor >>> (FilterToSQL) >>> >>> Rob Atkinson wrote: >>> >>> >>>> in FilterToSQL >>>> >>>> public Object visit(Literal expression, Object context) throws >>>> Class target = (Class)context; >>>> >>>> >>> If I remember correctly, the context (extraData) parameter is optional >>> and is basically whatever you want it to be. A null/instanceof check >>> should do the trick, unless the visitor really should blow chunks if it >>> doesn't have a context. >>> >>> Cory. >>> >>> ------------------------------------------------------------------------- >>> Take Surveys. Earn Cash. Influence the Future of IT >>> Join SourceForge.net's Techsay panel and you'll get the chance to share your >>> opinions on IT & business topics through brief surveys-and earn cash >>> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV >>> _______________________________________________ >>> Geotools-devel mailing list >>> [email protected] >>> https://lists.sourceforge.net/lists/listinfo/geotools-devel >>> >>> >>> >>> >>> ------------------------------------------------------------------------- >>> Take Surveys. Earn Cash. Influence the Future of IT >>> Join SourceForge.net's Techsay panel and you'll get the chance to share your >>> opinions on IT & business topics through brief surveys-and earn cash >>> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV >>> _______________________________________________ >>> Geotools-devel mailing list >>> [email protected] >>> https://lists.sourceforge.net/lists/listinfo/geotools-devel >>> >>> >> ------------------------------------------------------------------------- >> Take Surveys. Earn Cash. Influence the Future of IT >> Join SourceForge.net's Techsay panel and you'll get the chance to share your >> opinions on IT & business topics through brief surveys-and earn cash >> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV >> _______________________________________________ >> Geotools-devel mailing list >> [email protected] >> https://lists.sourceforge.net/lists/listinfo/geotools-devel >> > > > ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ Geotools-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geotools-devel
