What did you think of the idea of performing two tests (in order to maintain
performance).
So my performance question may be handled with an extra method:
1. short list property accessors that think they can handle the xpath
expresison using canHandle (this should be a test just to see if the xpath
expression is well formed for the purpose of the accessor)
2. Go through the short listed implementations using a canEvaulate method that
performs a more serious test against actual data (the feature type in this case)
3. Actually evaluate returning the value (or null if the value was null)
Justin's question is harder; what to do if nobody can handle the the
expression. Either because it is invalid; or does not match the data structure
(ie the invalid column name case). Can we safely return an expression in this
case? Or should we be returning null.
Jody
On 21/09/2010, at 11:57 AM, Niels wrote:
> I think it would be a good idea to make it optional and still throw a null
> value when this particular option is selected "off", like I first suggested.
> Question is only, at which point in time and in which manner this option is
> selected. Is it something that should be left completely to the users? For
> example in the case of app-schema, the problem was that non-existing columns
> in the mapping file can cause unclear exceptions. In this particular case it
> would be advised always to check on the existence of columns, while this
> might be different for other uses of expression evaluation.
>
> Remark that the patch also fixes something else that could cause bugs in the
> future.
> The way the XPath Property Accessor worked, it could easily prevent other
> property accessors from being used (when they are stored later in the queue -
> since xpath property accessor always returns true to canHandle), but still
> fail. (Refer to the earlier discussion with Jody.) That's why Jody suggested
> to actually try multiple property accessors. I think that is an important
> change that definitely should be kept.
>
> With Regards,
> Niels
>
> On 21/09/10 09:18, Justin Deoliveira wrote:
>>
>> Hi all,
>>
>> Recently this patch has been proposed:
>>
>> http://jira.codehaus.org/browse/GEOT-3066
>>
>> And this issue was discussed in detail on the mailing list some time ago in
>> this thread:
>>
>> http://osgeo-org.1803224.n2.nabble.com/evaluating-invalid-attribute-names-td5489979.html
>>
>>
>> Apologies for not weighing in then. But I think this has some pretty serious
>> backward compatibility issues. The issue/proposal is to throw an exception
>> vs return null when a type has no such attribute described by an attribute
>> name or xpath, rather than return null. The thread above proposes to just
>> change the behaviour and update any test cases that rely on it. I could not
>> disagree more with his approach. This breaks backward compatibility and i
>> think requires more discussion. There is much more use of geotools beyond
>> test cases and even beyond geoserver and udig. If there is one thing i
>> learned at foss4g it is that there are lots of people using geotools, even
>> though they don't take parts in discussions on the developer list.
>>
>> So i think this change requires more discussion and probably a proposal. And
>> it certainly can't take place on stable branch imo.
>>
>> Is there any way we can have this behaviour engage only when the user
>> explicitly requests it? That has been a pattern that has worked very well in
>> the past for such changes.
>>
>> -Justin
>>
>> --
>> Justin Deoliveira
>> OpenGeo - http://opengeo.org
>> Enterprise support for open source geospatial.
>>
>
>
> --
> Niels Charlier
>
> Software Engineer
> CSIRO Earth Science and Resource Engineering
> Phone: +61 8 6436 8914
>
> Australian Resources Research Centre
> 26 Dick Perry Avenue, Kensington WA 6151
> ------------------------------------------------------------------------------
> Start uncovering the many advantages of virtual appliances
> and start using them to simplify application deployment and
> accelerate your shift to cloud computing.
> http://p.sf.net/sfu/novell-sfdev2dev_______________________________________________
> Geotools-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/geotools-devel
------------------------------------------------------------------------------
Start uncovering the many advantages of virtual appliances
and start using them to simplify application deployment and
accelerate your shift to cloud computing.
http://p.sf.net/sfu/novell-sfdev2dev
_______________________________________________
Geotools-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geotools-devel
