To me, there is a big semantic difference between ignoreMismatch and
pruneMissing (even if they might function similarly). Setting
ignoreMismatch = true implies that I'm going to be intentionally
injecting typos (which doesn't sound like a good idea), while
pruneMissing implies that the query might not have all search terms
present and to omit those. The prune feature is especially useful in
user-entered search fields. If they omit search terms, Cayenne will
automatically remove those from the query and widen the search (which is
the desired effect).
I'd be more in favor of leaving pruneMissing alone and add another
method/variable (perhaps at the class level) to instruct Cayenne to
validate (or not) your map when it is processing expressions. If you
set this to false, it'll run a little faster because it doesn't need to
look for extra entries in the map that aren't present in the expression
-- extra entries could also be typos. Set to true, you get warnings
(good for development/debug), set to false, you get more speed (no
checking for extras) in production. And you can use a flag in your
config file to control it. Or a SOAP message. Or a secret URL to swap
it. Etc.
Anyway, just my $0.02 on the matter.
/dev/mrg
-----Original Message-----
From: Gili [mailto:cowwo..bs.darktech.org]
Sent: Friday, September 09, 2005 11:56 AM
To: cayenne-deve..bjectstyle.org
Subject: Re: SelectQuery.queryWithParameters(ignoreMismatch)
Well, I don't think this will affect your performance. Remember,
I'd be
using ignoreMismatch = false while you'd be using ignoreMismatch =
true... The implementation for ignoreMismatch = true is identical to
what it currently is for pruneMissing = true so you should see the same
performance. As for using the constant FOO approach it's really not
enough. In my case I was sending in parameters to the query whereas its
qualifier was completely empty. Debugging/testing will help, to be sure,
but you'd find the error *much* faster if Cayenne would warn you about
it (with ignoreMismatch = false). So, do you mind if I open up a RFE for
this and send in some patches?
Gili
Gentry, Michael (Contractor) wrote:
> I love the pruneMissing feature, personally. I could see perhaps
> wanting Cayenne to warn you (via a log message or something) if you
> provide Map entries which don't fit into the expression (in case of
> typos). This would slow it down a tad, though.
>
> Alternatively, you could also create constant strings to help out.
>
> public fooMethod()
> {
> final String FOO = "myFooVariable";
> ...
> }
>
> Then just reference FOO instead of "myFooVariable" whenever you need
to
> use it. Of course, you'd have to be careful to include the $ in your
> expression, but that's what debugging and testing is for, right? :-)
>
> /dev/mrg
>
>
>
> -----Original Message-----
> From: Gili [mailto:cowwo..bs.darktech.org]
> Sent: Thursday, September 08, 2005 11:36 PM
> To: cayenne-deve..bjectstyle.org
> Subject: SelectQuery.queryWithParameters(ignoreMismatch)
>
>
> Hi,
>
> I'd like to propose we modify
>
> queryWithParameters(java.util.Map parameters, boolean pruneMissing)
>
> to
>
> queryWithParameters(java.util.Map parameters, boolean ignoreMismatch)
>
> where "ignoreMismatch" is the equivilent of "pruneMissing" as
> well as
> ignoring when the user provides too many parameters.
>
> I bring this up because I ran into a situation where I was
> running a
> SelectQuery and it was consistently failing to behave as I expected.
> After further investigation I noticed that my mapped SelectQuery's
> qualifier string was incorrect. Something as simple as a typo in the
> qualifier string is enough to cause the query to fail silently.
>
> We should be able to execute in some sort of "strict mode" where
>
> Cayenne throws an exception if too little or too many parameters are
> provided (frankly, I'd love for strict mode to be the default -- right
> now the opposite is true). I'm willing to work on this if you guys
okay
> this change. What do you think?
>
> Gili
-- http://www.desktopbeautifier.com/
This archive was generated by hypermail 2.0.0 : Fri Sep 09 2005 - 12:09:11 EDT