Neils and myself chatted it out. Here is the transcript.
[7:12pm] jdeolive: hi niels_
[7:12pm] jdeolive: niels_: while we wait for others, i have a few questions
[7:12pm] niels_: okay, good idea
[7:13pm] jdeolive: ok, first question, it sounds like originally you wanted
to set up the change in behaviour to be configurable by the user
[7:13pm] jdeolive: and have the default be the way it is now
[7:13pm] jdeolive: is that correct?
[7:13pm] niels_: yes
[7:14pm] niels_: that was my proposition
[7:14pm] niels_: but to be fairly honest, it was jody who said: just change
it and change all the tests
[7:14pm] jdeolive: yeah i realized that after reading the original thread
[7:14pm] jdeolive: bad jody
[7:15pm] jdeolive: ok, well i definitely agree that is the best and safest
way forward
[7:15pm] jdeolive: so the question becomes how to achieve that
[7:15pm] jdeolive: did you have an original idea of how to do that?
[7:17pm] niels_: well one idea I had (but be aware, I have only been working
on geotools/geoserver for a few weeks)
[7:17pm] niels_: to keep the API of the expression classes the way it is,
[7:17pm] niels_: we could make an alternative implementation of
attributeexpressionimpl
[7:18pm] niels_: and then somehow pass an argument to the cql compiler, who
passes it to the filter factory
[7:18pm] niels_: that tells it which kind of attribute expressions to create
[7:18pm] jdeolive: yeah that makes sense
[7:19pm] jdeolive: another idea might be
[7:19pm] niels_: and then app-schema, when it evaluates the mapping file
[7:19pm] niels_: it can do it that way
[7:19pm] niels_: hm?
[7:19pm] jdeolive: to have the existing implementation of
attributeexpression behave differently
[7:19pm] jdeolive: if it is given a simple feature, vs a complex one
[7:20pm] jdeolive: as i don't think there would really be any backwards
compatibility issues with changing the behaviour just for complex features
[7:20pm] jdeolive: does that make sense?
[7:21pm] niels_: yeah I hadn't thought of that
[7:22pm] jdeolive: might not be as clean but might be easier to implement
[7:22pm] niels_: it seems a bit arbitrary, though
[7:22pm] jdeolive: well we use that patten alot in geoserver
[7:23pm] jdeolive: if simple feature do something, if complex do something
else
[7:23pm] niels_: true
[7:23pm] jdeolive: i don';t have much of a preference
[7:23pm] jdeolive: my only concern is that the simple feature case remain
the same in terms of performance and behaviour
[7:25pm] niels_: I was just discussing this with Ben who arrived
[7:25pm] niels_: he reckons this wouldn't solve the problem completely for
app-schema though
[7:27pm] jdeolive: ok, just an idea
[7:27pm] jdeolive: so going with teh first alternative
[7:27pm] jdeolive: how do we inject the app-schema specific implementation
of attributeexpression
[7:31pm] niels_: sorry, Ben was explaining to me
[7:31pm] niels_: mappings can still have simple types, so it would be hard
to do it that way
[7:32pm] niels_: the attributeexpression is created from the filterfactory
[7:32pm] niels_: so either the filterfactory, or that which uses the
filterfactory, should know
[7:32pm] bencaradocdavies joined the chat room.
[7:33pm] jdeolive: maybe app-scheam could create a subclass of filterfactory
and make sure that it uses that... although filters are usually created
externally
[7:33pm] jdeolive: maybe app-schema could "morph" the filter on the way in
[7:33pm] jdeolive: and replace any attribute expressions with its own
[7:34pm] jdeolive: there is code that does similar stuff ing eotools
[7:34pm] jdeolive: there is a duplicating filter visitor that basically
copies a filter and hacks parts of it that it needs to
[7:34pm] jdeolive: for instance for reprojection purposes, where a filter is
specified in one projection but needs to be executed in a different
projection
[7:34pm] niels_: hmm could do, app-schema creates a CQL compiler who calls
the filter, so the other way to do it is pass the parameter to the CQL
compiler
[7:35pm] jdeolive: hmmm... but filters aren't always created via cql are
they?
[7:36pm] niels_: let me check something..
[7:37pm] niels_: hmm no they aren't
[7:38pm] niels_: I just observed that app-schema creates the expressions
that way
[7:40pm] niels_: hacking the filter is probably possible, I would have to
look in to that better to see how to do it safely though
[7:41pm] niels_: the other thing is Jody seemed to object the idea of having
two options
[7:41pm] jdeolive: i think i have a good exampel for you
[7:43pm] jdeolive: if you look at Datautilities.resolvePropertyNames() you
will see an example of a duplicating filter vistitor that hacks propertyName
expressions
[7:43pm] niels_: cool, that's exactly what I need
[7:46pm] niels_: I will look in to doing it that way then
[7:47pm] niels_: also, maybe I should explain why Jody and I were discussing
performance issues? because you didn't seem to understand why we were
discussing that
[7:47pm] niels_: it all has something to do with the XPathPropertyAccessor
[7:48pm] niels_: the attribute expression evaluator would try to find a
property accessor that returns 'true' on canHandle
[7:48pm] niels_: but XPathPropertyAccessor always returns true, therefore
property accessors that come later in the list would never be reached
[7:49pm] niels_: so my suggestion was to check in canHandle if it can
actually handle the x-path; but the issue with that is that would cause
performance issues
[7:49pm] niels_: I don't know if I explained that well?
[7:50pm] jdeolive: yup, i think i understand the issue
[7:50pm] jdeolive: and yeah... way back when we had to make sure that
SimpleFeaturePropertyAccessor was the first to execute
[7:50pm] jdeolive: and i think in your patch you put another one first in
the list
[7:50pm] jdeolive: but yeah... i think if we follow this approach the
performance issue goes away
[7:51pm] niels_: well, we concluded to use canHandle to make a shortlist,
not to definitely pick one.
[7:51pm] niels_: that's also part of the patch, and I would actually
probably keep it that way
[7:52pm] niels_: and xpathpropertyaccessor stillneeds to throw an exception
when it can't handle, otherwise the alternative attributeexpressionimpl
wouldn't be able to tell if the attribute exists or not
[7:52pm] niels_: the default attributeexpressionimpl can tehn just catch the
exception and return a null
[7:54pm] jdeolive: well the existing implementation of attirbuteexpression
does not change though with this approach right?
[7:54pm] jdeolive: am i missing something?
[7:55pm] niels_: yes I think it needs to change, but it will still behave
the same
[7:55pm] niels_: in any case the xpathpropertyaccessor will behave
differently, it will not be 'lenient' anymore (ignoring non existing paths
and returning null)
[7:56pm] niels_: the existing attributeexpression will now catch the
exception and return a null, so keeping its original behaviour forbackward
compatibility
[7:57pm] jdeolive: ahh ok, right i see what you are saying
[7:58pm] niels_: anyway, thanks for the discussion
[7:59pm] niels_: I will look in to the filter hack option, and if all goes
well I will make a new proposition that respects backward compatibility
[7:59pm] jdeolive: no problem, thanks for taking the time to talk through it
[7:59pm] jdeolive: i look forward to the patch
[7:59pm] niels_: if I need to discuss anything else, I will do it through
the list of course
[7:59pm] niels_: thanks
[8:00pm] niels_: see ya later
[8:00pm] jdeolive: sounds good, catch you later
On Wed, Sep 22, 2010 at 9:12 PM, Jody Garnett <[email protected]>wrote:
> I got stuck in a work meeting; what were the results of the IRC meeting?
> Jody
>
> On 22/09/2010, at 11:41 AM, Niels wrote:
>
> Sounds good to me.
>
> On 22/09/10 04:42, Jody Garnett wrote:
>
> Sounds good; note that the IRC meeting may be via Skype (often seems to be
> when chatting with CSIRO :-) ).
>
> Jody
>
> On 22/09/2010, at 2:09 AM, Justin Deoliveira wrote:
>
> Hi guys,
>
> I can stick around later for a meeting so around 9am perth time should be
> fine but i can't do it today. How about we do it wednesday/thursday?
>
> On Tue, Sep 21, 2010 at 2:06 AM, Ben Caradoc-Davies <
> [email protected]> wrote:
>
>> Justin mailed this list at 9:18am Perth time this morning. :-)
>>
>>
>> On 21/09/10 16:03, Charlier, Niels (CESRE, Kensington) wrote:
>>
>>> Hmmm.. 7am would be a bit difficult for me. At earliest 8:00AM
>>>
>>> On 21/09/10 15:42, Jody Garnett wrote:
>>> I am going to assume your meeting was intended for geotools-devel?
>>>
>>> Justin is in north America; so I recommend early morning (assuming it is
>>> possible for Justin to stay up late).
>>> -
>>> http://www.timeanddate.com/worldclock/meetingtime.html?month=9&day=22&year=2010&p1=240&p2=196&p3=55&p4=-1
>>>
>>> With that in mind there is a small window when we are all awake.
>>>
>>> in the interest of hitting justin during working hours how about:
>>> - Perth 7am
>>> - Sydney 9am
>>> - Calgary 5pm
>>>
>>> Jody
>>>
>>> On 21/09/2010, at 5:00 PM, Niels wrote:
>>>
>>> Hi,
>>>
>>> Can we all meet up on the IRC channel Tomorrow or Thursday?
>>> Topic to be discussed is:
>>> - How can non-existent attribute names be detected in an expression,
>>> without breaking the current attribute access behaviour.
>>>
>>> Please let us know which times you could possibly be available and then I
>>> will let you know again what the best time is for everyone.
>>>
>>> Provide UTC time or specify time zone
>>> http://www.timeanddate.com/worldclock/
>>>
>>> With Regards,
>>>
>>> --
>>> 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
>>>
>>>
>>>
>>> --
>>> 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
>>>
>>>
>>
>> --
>> Ben Caradoc-Davies <[email protected]>
>> Software Engineering Team Leader
>>
>> CSIRO Earth Science and Resource Engineering
>> Australian Resources Research Centre
>>
>
>
>
> --
> 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
>
>
>
--
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.
------------------------------------------------------------------------------
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
