I think we are comparing (slightly) apples and oranges ...
The pruneMissing flag is intended for when the right-hand side of the
expression can be missing, so you omit it from the map and that part of
the expression is pruned.
A strict mode flag would be intended for the left-hand side of the
expression. Different goals.
Or maybe I just don't understand what you are asking? It seems to me
you could set pruneMissing to false and Cayenne would let you know if
you specified variables not in the expression. Or maybe you are wanting
to be able to use pruneMissing (set to true), but have Cayenne ensure
that every parameter in the map matches one of the parameters in the
expression (no extras/typos)? (this last is what I thought you were
asking)
I think I need more caffeine ... and maybe lunch. :-)
/dev/mrg
-----Original Message-----
From: Gili [mailto:cowwo..bs.darktech.org]
Sent: Friday, September 09, 2005 12:30 PM
To: cayenne-deve..bjectstyle.org
Subject: Re: SelectQuery.queryWithParameters(ignoreMismatch)
How about we rename "ignoreMismatch" to "notStrict" then? :)
It's not
meant to imply that you're intentionally injecting typos but it's meant
to say that you're not expecting a one-to-one match between the query
definition and the parameters.
I don't mind creating a totally different method for strict
mode... and
I also think we should be able to enable/disable this at runtime so on a
production machine you'd disable strict checking even if the code
actually invokes it...
So... we'd have one method for pruneMissing, another for strict
mode.
If strict mode is used, it is like an assert in that we can disable it
at runtime for production machines and no noticable performance hit will
occur. Ideally, strict mode should be the default. pruneMissing is
definately useful, but I'd default error checking over assuming the user
is intentionally omitting parameters.
Gili
Gentry, Michael (Contractor) wrote:
> 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:53:02 EDT