You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@turbine.apache.org by Florian Lindauer <fl...@secure-net.de> on 2001/06/01 10:00:58 UTC
Re: Problem with Criterion and complex queries
John McNally wrote:
>
> I think a simple solution can be implemented. With the proposals
> currently in the works I do not see a reason to completely redesign
> Criteria. How about a flag to note which method was called first then
> that condition will be given the higher priority? I think that would be
> fairly intuitive, though I have not used the new convenience methods and
> do not know if it is as workable/intuitive as I imagine.
In my last post (perhaps you posted more ore less at the same time)
I mentioned that I thought of such a flag, too. But, this only holds
for expressions with a depth of two, like the discussed example,
or perhaps for some special expressions of greater depths, if you
exactly know how to construct them - but never generally.
Imagine that:
((a<1 or b<2) and (c<3 or d<4)) or ((a>5 or b>6) and (c>7 or d>8))
With a1.or(b2).and(c3.or(d4)) you get it right, as the and-chain
(containing c3-(and)-c4) is marked as binding less than the or-chain
(b2).
As soon as you again call or(), the new thing is appended to the back
of the or-chain and you again would have to change the flag to mark the
or-chain to bind less. The result:
((a<1 and (c<3 or d<4)) or (b2 or ((a>5 or b>6) and (c>7 or d>8)))
I hope, reading Erics and my former posts again, we can convince you
there is a conceptual problem achieving general where-expressions with
the given criterion-linkage concept.
And still I hope after further examination you both come to the
decision that my diff can be added without risk but only benefits.
The above example:
Criteria.Connector
con1=crit.getNewConnector(a1.or(b2),c3.or(d4),Criteria.CTYPE_AND);
Criteria.Connector
con2=crit.getNewConnector(a5.or(b6),c7.or(d8),Criteria.CTYPE_AND);
crit.add(crit.getNewConnector(con1,con2,Criteria.CONN_TYPE_OR));
--
Florian Lindauer
_________________________________________
SecureNet GmbH * http://www.secure-net.de
Phone +49 89/32133-662 * fl@secure-net.de
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-user-help@jakarta.apache.org
Re: Problem with Criterion and complex queries
Posted by Daniel Rall <dl...@finemaltcoding.com>.
John McNally <jm...@collab.net> writes:
> I am dropping my original proposal and if Eric does not come up with a
> preferred solution soon, we will probably accept yours. I have some
> question on the toString() method. Can the code be structured to append
> to a common StringBuffer? As few conversion between String and
> StringBuffer as possible is a desired goal.
+1, this is an important design goal to keep the code as efficient as
possible.
Dan
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-user-help@jakarta.apache.org
Re: Problem with Criterion and complex queries
Posted by Daniel Rall <dl...@finemaltcoding.com>.
Florian Lindauer <fl...@secure-net.de> writes:
> I was not so aware that String-concatenation is so expensive,
> i.e. that it is implicitly done by converting to StringBuffer(?).
String in Java are immutable, so every time you concatentate two
Strings, you have *three* String object in memory at the peak. A
StringBuffer is roughly analogous to a dynamically resizable C char*
buffer, much more efficient than immutable Strings.
String concatentation in non-loop, non-branching situations (i.e. s +
"foo") is generally implicitly converted into StringBuffer calls by
a Java compiler.
Daniel
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-user-help@jakarta.apache.org
Re: Problem with Criterion and complex queries
Posted by Florian Lindauer <fl...@secure-net.de>.
John McNally wrote:
>
> I am dropping my original proposal and if Eric does not come up with a
> preferred solution soon, we will probably accept yours. I have some
> question on the toString() method. Can the code be structured to append
> to a common StringBuffer? As few conversion between String and
> StringBuffer as possible is a desired goal.
I was not so aware that String-concatenation is so expensive,
i.e. that it is implicitly done by converting to StringBuffer(?).
I guess, it would look like the following then:
StringBuffer sb=new StringBuffer();
sb.append("(");
sb.append(object1.toString());
if (connection_type==CONN_TYPE_AND)
sb.append(Criterion.AND);
else
sb.append(Criterion.OR);
sb.append(object2.toString());
sb.append(")");
return sb.toString();
Of course in analogy to appendPsTo one could use another method
than toString() to build the SQL using only StringBuffers. But this
would require changes in BasePeer at least.
Now, Eric did come up with (plans to) a better solution, so lets
see if we need this..
Florian Lindauer
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-user-help@jakarta.apache.org
Re: Problem with Criterion and complex queries
Posted by John McNally <jm...@collab.net>.
I am dropping my original proposal and if Eric does not come up with a
preferred solution soon, we will probably accept yours. I have some
question on the toString() method. Can the code be structured to append
to a common StringBuffer? As few conversion between String and
StringBuffer as possible is a desired goal.
john mcnally
Florian Lindauer wrote:
>
> John McNally wrote:
> >
> > I think a simple solution can be implemented. With the proposals
> > currently in the works I do not see a reason to completely redesign
> > Criteria. How about a flag to note which method was called first then
> > that condition will be given the higher priority? I think that would be
> > fairly intuitive, though I have not used the new convenience methods and
> > do not know if it is as workable/intuitive as I imagine.
>
> In my last post (perhaps you posted more ore less at the same time)
> I mentioned that I thought of such a flag, too. But, this only holds
> for expressions with a depth of two, like the discussed example,
> or perhaps for some special expressions of greater depths, if you
> exactly know how to construct them - but never generally.
> Imagine that:
>
> ((a<1 or b<2) and (c<3 or d<4)) or ((a>5 or b>6) and (c>7 or d>8))
>
> With a1.or(b2).and(c3.or(d4)) you get it right, as the and-chain
> (containing c3-(and)-c4) is marked as binding less than the or-chain
> (b2).
> As soon as you again call or(), the new thing is appended to the back
> of the or-chain and you again would have to change the flag to mark the
> or-chain to bind less. The result:
>
> ((a<1 and (c<3 or d<4)) or (b2 or ((a>5 or b>6) and (c>7 or d>8)))
>
> I hope, reading Erics and my former posts again, we can convince you
> there is a conceptual problem achieving general where-expressions with
> the given criterion-linkage concept.
>
> And still I hope after further examination you both come to the
> decision that my diff can be added without risk but only benefits.
>
> The above example:
>
> Criteria.Connector
> con1=crit.getNewConnector(a1.or(b2),c3.or(d4),Criteria.CTYPE_AND);
> Criteria.Connector
> con2=crit.getNewConnector(a5.or(b6),c7.or(d8),Criteria.CTYPE_AND);
> crit.add(crit.getNewConnector(con1,con2,Criteria.CONN_TYPE_OR));
>
> --
> Florian Lindauer
> _________________________________________
> SecureNet GmbH * http://www.secure-net.de
> Phone +49 89/32133-662 * fl@secure-net.de
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: turbine-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: turbine-user-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-user-help@jakarta.apache.org