Re: SelectQuery.queryWithParameters(ignoreMismatch)

From: Mike Kienenberger (mkienen..mail.com)
Date: Fri Sep 09 2005 - 12:04:10 EDT

  • Next message: Mike Kienenberger: "Re: context.deleteObjects() fails silently"

    I think what Michael is saying is that doing additional checking for
    unused parameters is going to add additional performance issues.
    Currently, it only checks for missing parameters.

    I also think this needs to be a separate parameter rather than an
    enhancement of the existing parameter since it is not backward
    compatible. It puts an extra constraint on the parameter map passed
    (no extraneous parameters).

    That said, I'd prefer to use a method that did extra checking over one
    that that didn't.

    On 9/9/05, Gili <cowwo..bs.darktech.org> wrote:
    >
    > 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:04:12 EDT