We're talking a lot about Doctrine 2.0 and this time I'm coming here to talk about DQL changes. String processing is something really weird, and we want to remove, since it's extremely error-prone.
Basically the purpose of this email is about WHERE conditions. We end up with a lot of possibilities, and we want all of you to give us suggestions about which way we should move to. Here are the possibilities we came so far: http://pastebin.com/f4f6c2aa0
If you have any other suggestions, include them here too. We expect to find the simplest way to build a query without adding too much WTF factor inside.
So, what's your ideas?
Cheers,
-- Guilherme Blanco - Web Developer CBC - Certified Bindows Consultant Cell Phone: +55 (16) 9215-8480 MSN: guilhermebla...@hotmail.com URL: http://blog.bisna.com São Paulo - SP/Brazil
Possibility #1 is the most expressive and easiest to read, IMO. I like the variant, even though it's more verbose, because it feels a little more flexible.
> -----Original Message-----
> From: doctrine-dev@googlegroups.com [mailto:doctrine-
> dev@googlegroups.com] On Behalf Of Guilherme Blanco
> Sent: Thursday, May 28, 2009 1:55 PM
> To: doctrine-dev@googlegroups.com
> Subject: [doctrine-dev] New DQL Criteria API
> Hi guys,
> We're talking a lot about Doctrine 2.0 and this time I'm coming here
> to talk about DQL changes.
> String processing is something really weird, and we want to remove,
> since it's extremely error-prone.
> Basically the purpose of this email is about WHERE conditions.
> We end up with a lot of possibilities, and we want all of you to give
> us suggestions about which way we should move to.
> Here are the possibilities we came so far:
> http://pastebin.com/f4f6c2aa0
> If you have any other suggestions, include them here too.
> We expect to find the simplest way to build a query without adding too
> much WTF factor inside.
I only want to clarify what this discussion is about.
We have the Query class. It accepts full DQL strings. You can always
build any DQL query through string concatenation.
The issue with that is just that *conditional* query construction (if
parameter A set condition X, if parameter B, set condition B OR C)
is cumbersome using string concatenation.
That is what the QueryBuilder class should be useful for.
And what we're now wondering is what the best and safest way is to
construct expressions with the QueryBuilder API.
It does add nothing in terms of functionality. Just a different way to
construct queries that is more suitable if the construction is based
on conditions.
> Possibility #1 is the most expressive and easiest to read, IMO. I
> like the variant, even though it's more verbose, because it feels a
> little more flexible.
> > -----Original Message-----
> > From: doctrine-dev@googlegroups.com [mailto:doctrine-
> > dev@googlegroups.com] On Behalf Of Guilherme Blanco
> > Sent: Thursday, May 28, 2009 1:55 PM
> > To: doctrine-dev@googlegroups.com
> > Subject: [doctrine-dev] New DQL Criteria API
> > Hi guys,
> > We're talking a lot about Doctrine 2.0 and this time I'm coming here
> > to talk about DQL changes.
> > String processing is something really weird, and we want to remove,
> > since it's extremely error-prone.
> > Basically the purpose of this email is about WHERE conditions.
> > We end up with a lot of possibilities, and we want all of you to
> give
> > us suggestions about which way we should move to.
> > Here are the possibilities we came so far:
> > http://pastebin.com/f4f6c2aa0
> > If you have any other suggestions, include them here too.
> > We expect to find the simplest way to build a query without adding
> too
> > much WTF factor inside.
I think that #2 and #3 are the best options for me. They are well
known from the 1.* branch, so it will be also easier to migrate.
I hope that it will be still possible to write conditions in the old way:
->addWhere('(m.attr1 = ? AND (m.attr2 = ? OR m.attr2 = ?)) OR m.attr3
= ?', array($var, ...));
instead of separating each part of the condition into separate
parameter of where functions.
I like doctrine beacuse of the DQL it have. It is clear and very
similar to SQL.
> I only want to clarify what this discussion is about.
> We have the Query class. It accepts full DQL strings. You can always build
> any DQL query through string concatenation.
> The issue with that is just that *conditional* query construction (if
> parameter A set condition X, if parameter B, set condition B OR C)
> is cumbersome using string concatenation.
> That is what the QueryBuilder class should be useful for.
> And what we're now wondering is what the best and safest way is to construct
> expressions with the QueryBuilder API.
> It does add nothing in terms of functionality. Just a different way to
> construct queries that is more suitable if the construction is based on
> conditions.
> Regards
> Roman
> On May 28, 2009, at 7:58 PM, Adam Huttler wrote:
> Possibility #1 is the most expressive and easiest to read, IMO. I like the
> variant, even though it's more verbose, because it feels a little more
> flexible.
>> -----Original Message-----
>> From: doctrine-dev@googlegroups.com [mailto:doctrine-
>> dev@googlegroups.com] On Behalf Of Guilherme Blanco
>> Sent: Thursday, May 28, 2009 1:55 PM
>> To: doctrine-dev@googlegroups.com
>> Subject: [doctrine-dev] New DQL Criteria API
>> Hi guys,
>> We're talking a lot about Doctrine 2.0 and this time I'm coming here
>> to talk about DQL changes.
>> String processing is something really weird, and we want to remove,
>> since it's extremely error-prone.
>> Basically the purpose of this email is about WHERE conditions.
>> We end up with a lot of possibilities, and we want all of you to give
>> us suggestions about which way we should move to.
>> Here are the possibilities we came so far:
>> http://pastebin.com/f4f6c2aa0
>> If you have any other suggestions, include them here too.
>> We expect to find the simplest way to build a query without adding too
>> much WTF factor inside.
To make the new API useful, one should bear in mind that:
- you'll want to preserve the mental process people use to write a
query, which includes the order of conditions
- "OR" and "AND" are binary operations taking an argument on each side
- you'll want to maintain the monadic behavior, so operations can be
chained
These base assumptions kind of discard option #1, which would force
you to reorder the way you write a query.
Option #2 is a good start, but ->where('(')) and ->where(')')
will be used so often that they could use a proper name. Which leads
us to Option #3.
Option #3 seems the best insofar, but I would consider "Block" instead
of "Sub" - it makes more sense because two pairs of parenthesis with
an operation in between are not "subs" seeing as they are at the same
level. Example: ((A and B) OR (C and D))
If you do add a beginBlock, please also add a beginBlockIf(boolean).
It would allow constructing queries in one go, as opposed to breaking
the chain to interpose if() calls.
In both Option #3 and #4 I would make ->or() and ->and() a top-level
function, which would lead us to the Variants
Possibility #4 is also good, but I would maybe replace ->add('OR')
with a simple ->or():
I took the liberty of adding #3.1 and #4.2 to illustrate these points.
Thank you for taking the time to have this discussion, it's
appreciated.
Best regards,
- Jorge Pereira
On 28 May, 19:12, Roman Borschel <r.borsc...@gmx.net> wrote:
> I only want to clarify what this discussion is about.
> We have the Query class. It accepts full DQL strings. You can always
> build any DQL query through string concatenation.
> The issue with that is just that *conditional* query construction (if
> parameter A set condition X, if parameter B, set condition B OR C)
> is cumbersome using string concatenation.
> That is what the QueryBuilder class should be useful for.
> And what we're now wondering is what the best and safest way is to
> construct expressions with the QueryBuilder API.
> It does add nothing in terms of functionality. Just a different way to
> construct queries that is more suitable if the construction is based
> on conditions.
> Regards
> Roman
> On May 28, 2009, at 7:58 PM, Adam Huttler wrote:
> > Possibility #1 is the most expressive and easiest to read, IMO. I
> > like the variant, even though it's more verbose, because it feels a
> > little more flexible.
> > > -----Original Message-----
> > > From: doctrine-dev@googlegroups.com [mailto:doctrine-
> > > dev@googlegroups.com] On Behalf Of Guilherme Blanco
> > > Sent: Thursday, May 28, 2009 1:55 PM
> > > To: doctrine-dev@googlegroups.com
> > > Subject: [doctrine-dev] New DQL Criteria API
> > > Hi guys,
> > > We're talking a lot about Doctrine 2.0 and this time I'm coming here
> > > to talk about DQL changes.
> > > String processing is something really weird, and we want to remove,
> > > since it's extremely error-prone.
> > > Basically the purpose of this email is about WHERE conditions.
> > > We end up with a lot of possibilities, and we want all of you to
> > give
> > > us suggestions about which way we should move to.
> > > Here are the possibilities we came so far:
> > >http://pastebin.com/f4f6c2aa0
> > > If you have any other suggestions, include them here too.
> > > We expect to find the simplest way to build a query without adding
> > too
> > > much WTF factor inside.
I finally made my final decision (it's not yet the official one of
Doctrine)... I'd go with #4 variation.
I was in doubt between #1 variant and #4 variant.
About DQL as string support... we can include the support to this (in
my personal decision):
$w = Expr::where();
$w->add(Expr::literal('m.attr1 = ?0 AND m.attr2 = ?1')) // WHERE
m.attr1 = ?0 AND m.attr2 = ?1
$q->add($w); // $q is instance of Query
> I think that #2 and #3 are the best options for me. They are well
> known from the 1.* branch, so it will be also easier to migrate.
> I hope that it will be still possible to write conditions in the old way:
> ->addWhere('(m.attr1 = ? AND (m.attr2 = ? OR m.attr2 = ?)) OR m.attr3
> = ?', array($var, ...));
> instead of separating each part of the condition into separate
> parameter of where functions.
> I like doctrine beacuse of the DQL it have. It is clear and very
> similar to SQL.
> ~
> adrive
> 2009/5/28 Roman Borschel <r.borsc...@gmx.net>:
>> I only want to clarify what this discussion is about.
>> We have the Query class. It accepts full DQL strings. You can always build
>> any DQL query through string concatenation.
>> The issue with that is just that *conditional* query construction (if
>> parameter A set condition X, if parameter B, set condition B OR C)
>> is cumbersome using string concatenation.
>> That is what the QueryBuilder class should be useful for.
>> And what we're now wondering is what the best and safest way is to construct
>> expressions with the QueryBuilder API.
>> It does add nothing in terms of functionality. Just a different way to
>> construct queries that is more suitable if the construction is based on
>> conditions.
>> Regards
>> Roman
>> On May 28, 2009, at 7:58 PM, Adam Huttler wrote:
>> Possibility #1 is the most expressive and easiest to read, IMO. I like the
>> variant, even though it's more verbose, because it feels a little more
>> flexible.
>>> -----Original Message-----
>>> From: doctrine-dev@googlegroups.com [mailto:doctrine-
>>> dev@googlegroups.com] On Behalf Of Guilherme Blanco
>>> Sent: Thursday, May 28, 2009 1:55 PM
>>> To: doctrine-dev@googlegroups.com
>>> Subject: [doctrine-dev] New DQL Criteria API
>>> Hi guys,
>>> We're talking a lot about Doctrine 2.0 and this time I'm coming here
>>> to talk about DQL changes.
>>> String processing is something really weird, and we want to remove,
>>> since it's extremely error-prone.
>>> Basically the purpose of this email is about WHERE conditions.
>>> We end up with a lot of possibilities, and we want all of you to give
>>> us suggestions about which way we should move to.
>>> Here are the possibilities we came so far:
>>> http://pastebin.com/f4f6c2aa0
>>> If you have any other suggestions, include them here too.
>>> We expect to find the simplest way to build a query without adding too
>>> much WTF factor inside.
On Thu, May 28, 2009 at 4:17 PM, Jorge Pereira <jpereira...@gmail.com> wrote:
> Hi,
> This is an interesting topic.
> To make the new API useful, one should bear in mind that:
> - you'll want to preserve the mental process people use to write a
> query, which includes the order of conditions
> - "OR" and "AND" are binary operations taking an argument on each side
> - you'll want to maintain the monadic behavior, so operations can be
> chained
> These base assumptions kind of discard option #1, which would force
> you to reorder the way you write a query.
> Option #2 is a good start, but ->where('(')) and ->where(')')
> will be used so often that they could use a proper name. Which leads
> us to Option #3.
> Option #3 seems the best insofar, but I would consider "Block" instead
> of "Sub" - it makes more sense because two pairs of parenthesis with
> an operation in between are not "subs" seeing as they are at the same
> level. Example: ((A and B) OR (C and D))
> If you do add a beginBlock, please also add a beginBlockIf(boolean).
> It would allow constructing queries in one go, as opposed to breaking
> the chain to interpose if() calls.
> In both Option #3 and #4 I would make ->or() and ->and() a top-level
> function, which would lead us to the Variants
> Possibility #4 is also good, but I would maybe replace ->add('OR')
> with a simple ->or():
> I took the liberty of adding #3.1 and #4.2 to illustrate these points.
> Thank you for taking the time to have this discussion, it's
> appreciated.
> Best regards,
> - Jorge Pereira
> On 28 May, 19:12, Roman Borschel <r.borsc...@gmx.net> wrote:
>> I only want to clarify what this discussion is about.
>> We have the Query class. It accepts full DQL strings. You can always
>> build any DQL query through string concatenation.
>> The issue with that is just that *conditional* query construction (if
>> parameter A set condition X, if parameter B, set condition B OR C)
>> is cumbersome using string concatenation.
>> That is what the QueryBuilder class should be useful for.
>> And what we're now wondering is what the best and safest way is to
>> construct expressions with the QueryBuilder API.
>> It does add nothing in terms of functionality. Just a different way to
>> construct queries that is more suitable if the construction is based
>> on conditions.
>> Regards
>> Roman
>> On May 28, 2009, at 7:58 PM, Adam Huttler wrote:
>> > Possibility #1 is the most expressive and easiest to read, IMO. I
>> > like the variant, even though it's more verbose, because it feels a
>> > little more flexible.
>> > > -----Original Message-----
>> > > From: doctrine-dev@googlegroups.com [mailto:doctrine-
>> > > dev@googlegroups.com] On Behalf Of Guilherme Blanco
>> > > Sent: Thursday, May 28, 2009 1:55 PM
>> > > To: doctrine-dev@googlegroups.com
>> > > Subject: [doctrine-dev] New DQL Criteria API
>> > > Hi guys,
>> > > We're talking a lot about Doctrine 2.0 and this time I'm coming here
>> > > to talk about DQL changes.
>> > > String processing is something really weird, and we want to remove,
>> > > since it's extremely error-prone.
>> > > Basically the purpose of this email is about WHERE conditions.
>> > > We end up with a lot of possibilities, and we want all of you to
>> > give
>> > > us suggestions about which way we should move to.
>> > > Here are the possibilities we came so far:
>> > >http://pastebin.com/f4f6c2aa0
>> > > If you have any other suggestions, include them here too.
>> > > We expect to find the simplest way to build a query without adding
>> > too
>> > > much WTF factor inside.
> I only want to clarify what this discussion is about.
> We have the Query class. It accepts full DQL strings. You can always
> build any DQL query through string concatenation.
> The issue with that is just that *conditional* query construction (if
> parameter A set condition X, if parameter B, set condition B OR C)
> is cumbersome using string concatenation.
> That is what the QueryBuilder class should be useful for.
> And what we're now wondering is what the best and safest way is to
> construct expressions with the QueryBuilder API.
> It does add nothing in terms of functionality. Just a different way to
> construct queries that is more suitable if the construction is based
> on conditions.
> Regards
> Roman
> On May 28, 2009, at 7:58 PM, Adam Huttler wrote:
> > Possibility #1 is the most expressive and easiest to read, IMO. I
> > like the variant, even though it's more verbose, because it feels a
> > little more flexible.
> > > -----Original Message-----
> > > From: doctrine-dev@googlegroups.com [mailto:doctrine-
> > > dev@googlegroups.com] On Behalf Of Guilherme Blanco
> > > Sent: Thursday, May 28, 2009 1:55 PM
> > > To: doctrine-dev@googlegroups.com
> > > Subject: [doctrine-dev] New DQL Criteria API
> > > Hi guys,
> > > We're talking a lot about Doctrine 2.0 and this time I'm coming here
> > > to talk about DQL changes.
> > > String processing is something really weird, and we want to remove,
> > > since it's extremely error-prone.
> > > Basically the purpose of this email is about WHERE conditions.
> > > We end up with a lot of possibilities, and we want all of you to
> > give
> > > us suggestions about which way we should move to.
> > > Here are the possibilities we came so far:
> > >http://pastebin.com/f4f6c2aa0
> > > If you have any other suggestions, include them here too.
> > > We expect to find the simplest way to build a query without adding
> > too
> > > much WTF factor inside.
> You need to paste the link it generates here... otherwise we can't see
> your approach.
> Cheers,
> On Thu, May 28, 2009 at 4:17 PM, Jorge Pereira
> <jpereira...@gmail.com> wrote:
>> Hi,
>> This is an interesting topic.
>> To make the new API useful, one should bear in mind that:
>> - you'll want to preserve the mental process people use to write a
>> query, which includes the order of conditions
>> - "OR" and "AND" are binary operations taking an argument on each
>> side
>> - you'll want to maintain the monadic behavior, so operations can be
>> chained
>> These base assumptions kind of discard option #1, which would force
>> you to reorder the way you write a query.
>> Option #2 is a good start, but ->where('(')) and ->where(')')
>> will be used so often that they could use a proper name. Which leads
>> us to Option #3.
>> Option #3 seems the best insofar, but I would consider "Block"
>> instead
>> of "Sub" - it makes more sense because two pairs of parenthesis with
>> an operation in between are not "subs" seeing as they are at the same
>> level. Example: ((A and B) OR (C and D))
>> If you do add a beginBlock, please also add a beginBlockIf(boolean).
>> It would allow constructing queries in one go, as opposed to breaking
>> the chain to interpose if() calls.
>> In both Option #3 and #4 I would make ->or() and ->and() a top-level
>> function, which would lead us to the Variants
>> Possibility #4 is also good, but I would maybe replace ->add('OR')
>> with a simple ->or():
>> I took the liberty of adding #3.1 and #4.2 to illustrate these
>> points.
>> Thank you for taking the time to have this discussion, it's
>> appreciated.
>> Best regards,
>> - Jorge Pereira
>> On 28 May, 19:12, Roman Borschel <r.borsc...@gmx.net> wrote:
>>> I only want to clarify what this discussion is about.
>>> We have the Query class. It accepts full DQL strings. You can always
>>> build any DQL query through string concatenation.
>>> The issue with that is just that *conditional* query construction
>>> (if
>>> parameter A set condition X, if parameter B, set condition B OR C)
>>> is cumbersome using string concatenation.
>>> That is what the QueryBuilder class should be useful for.
>>> And what we're now wondering is what the best and safest way is to
>>> construct expressions with the QueryBuilder API.
>>> It does add nothing in terms of functionality. Just a different
>>> way to
>>> construct queries that is more suitable if the construction is based
>>> on conditions.
>>> Regards
>>> Roman
>>> On May 28, 2009, at 7:58 PM, Adam Huttler wrote:
>>>> Possibility #1 is the most expressive and easiest to read, IMO. I
>>>> like the variant, even though it's more verbose, because it feels a
>>>> little more flexible.
>>>>> -----Original Message-----
>>>>> From: doctrine-dev@googlegroups.com [mailto:doctrine-
>>>>> dev@googlegroups.com] On Behalf Of Guilherme Blanco
>>>>> Sent: Thursday, May 28, 2009 1:55 PM
>>>>> To: doctrine-dev@googlegroups.com
>>>>> Subject: [doctrine-dev] New DQL Criteria API
>>>>> Hi guys,
>>>>> We're talking a lot about Doctrine 2.0 and this time I'm coming
>>>>> here
>>>>> to talk about DQL changes.
>>>>> String processing is something really weird, and we want to
>>>>> remove,
>>>>> since it's extremely error-prone.
>>>>> Basically the purpose of this email is about WHERE conditions.
>>>>> We end up with a lot of possibilities, and we want all of you to
>>>> give
>>>>> us suggestions about which way we should move to.
>>>>> Here are the possibilities we came so far:
>>>>> http://pastebin.com/f4f6c2aa0
>>>>> If you have any other suggestions, include them here too.
>>>>> We expect to find the simplest way to build a query without adding
>>>> too
>>>>> much WTF factor inside.
>>>>> So, what's your ideas?
>>>>> Cheers,
>>>>> --
>>>>> Guilherme Blanco - Web Developer
>>>>> CBC - Certified Bindows Consultant
>>>>> Cell Phone: +55 (16) 9215-8480
>>>>> MSN: guilhermebla...@hotmail.com
>>>>> URL:http://blog.bisna.com >>>>> São Paulo - SP/Brazil
> You need to paste the link it generates here... otherwise we can't see
> your approach.
> Cheers,
> On Thu, May 28, 2009 at 4:17 PM, Jorge Pereira <jpereira...@gmail.com> wrote:
> > Hi,
> > This is an interesting topic.
> > To make the new API useful, one should bear in mind that:
> > - you'll want to preserve the mental process people use to write a
> > query, which includes the order of conditions
> > - "OR" and "AND" are binary operations taking an argument on each side
> > - you'll want to maintain the monadic behavior, so operations can be
> > chained
> > These base assumptions kind of discard option #1, which would force
> > you to reorder the way you write a query.
> > Option #2 is a good start, but ->where('(')) and ->where(')')
> > will be used so often that they could use a proper name. Which leads
> > us to Option #3.
> > Option #3 seems the best insofar, but I would consider "Block" instead
> > of "Sub" - it makes more sense because two pairs of parenthesis with
> > an operation in between are not "subs" seeing as they are at the same
> > level. Example: ((A and B) OR (C and D))
> > If you do add a beginBlock, please also add a beginBlockIf(boolean).
> > It would allow constructing queries in one go, as opposed to breaking
> > the chain to interpose if() calls.
> > In both Option #3 and #4 I would make ->or() and ->and() a top-level
> > function, which would lead us to the Variants
> > Possibility #4 is also good, but I would maybe replace ->add('OR')
> > with a simple ->or():
> > I took the liberty of adding #3.1 and #4.2 to illustrate these points.
> > Thank you for taking the time to have this discussion, it's
> > appreciated.
> > Best regards,
> > - Jorge Pereira
> > On 28 May, 19:12, Roman Borschel <r.borsc...@gmx.net> wrote:
> >> I only want to clarify what this discussion is about.
> >> We have the Query class. It accepts full DQL strings. You can always
> >> build any DQL query through string concatenation.
> >> The issue with that is just that *conditional* query construction (if
> >> parameter A set condition X, if parameter B, set condition B OR C)
> >> is cumbersome using string concatenation.
> >> That is what the QueryBuilder class should be useful for.
> >> And what we're now wondering is what the best and safest way is to
> >> construct expressions with the QueryBuilder API.
> >> It does add nothing in terms of functionality. Just a different way to
> >> construct queries that is more suitable if the construction is based
> >> on conditions.
> >> Regards
> >> Roman
> >> On May 28, 2009, at 7:58 PM, Adam Huttler wrote:
> >> > Possibility #1 is the most expressive and easiest to read, IMO. I
> >> > like the variant, even though it's more verbose, because it feels a
> >> > little more flexible.
> >> > > -----Original Message-----
> >> > > From: doctrine-dev@googlegroups.com [mailto:doctrine-
> >> > > dev@googlegroups.com] On Behalf Of Guilherme Blanco
> >> > > Sent: Thursday, May 28, 2009 1:55 PM
> >> > > To: doctrine-dev@googlegroups.com
> >> > > Subject: [doctrine-dev] New DQL Criteria API
> >> > > Hi guys,
> >> > > We're talking a lot about Doctrine 2.0 and this time I'm coming here
> >> > > to talk about DQL changes.
> >> > > String processing is something really weird, and we want to remove,
> >> > > since it's extremely error-prone.
> >> > > Basically the purpose of this email is about WHERE conditions.
> >> > > We end up with a lot of possibilities, and we want all of you to
> >> > give
> >> > > us suggestions about which way we should move to.
> >> > > Here are the possibilities we came so far:
> >> > >http://pastebin.com/f4f6c2aa0
> >> > > If you have any other suggestions, include them here too.
> >> > > We expect to find the simplest way to build a query without adding
> >> > too
> >> > > much WTF factor inside.
> There is a link at the top of your paste Guilherme. "View followups
> from guilhermeblanco and Jorge Pereira"
> Roman
> On May 28, 2009, at 9:24 PM, Guilherme Blanco wrote:
> > You need to paste the link it generates here... otherwise we can't see
> > your approach.
> > Cheers,
> > On Thu, May 28, 2009 at 4:17 PM, Jorge Pereira
> > <jpereira...@gmail.com> wrote:
> >> Hi,
> >> This is an interesting topic.
> >> To make the new API useful, one should bear in mind that:
> >> - you'll want to preserve the mental process people use to write a
> >> query, which includes the order of conditions
> >> - "OR" and "AND" are binary operations taking an argument on each
> >> side
> >> - you'll want to maintain the monadic behavior, so operations can be
> >> chained
> >> These base assumptions kind of discard option #1, which would force
> >> you to reorder the way you write a query.
> >> Option #2 is a good start, but ->where('(')) and ->where(')')
> >> will be used so often that they could use a proper name. Which leads
> >> us to Option #3.
> >> Option #3 seems the best insofar, but I would consider "Block"
> >> instead
> >> of "Sub" - it makes more sense because two pairs of parenthesis with
> >> an operation in between are not "subs" seeing as they are at the same
> >> level. Example: ((A and B) OR (C and D))
> >> If you do add a beginBlock, please also add a beginBlockIf(boolean).
> >> It would allow constructing queries in one go, as opposed to breaking
> >> the chain to interpose if() calls.
> >> In both Option #3 and #4 I would make ->or() and ->and() a top-level
> >> function, which would lead us to the Variants
> >> Possibility #4 is also good, but I would maybe replace ->add('OR')
> >> with a simple ->or():
> >> I took the liberty of adding #3.1 and #4.2 to illustrate these
> >> points.
> >> Thank you for taking the time to have this discussion, it's
> >> appreciated.
> >> Best regards,
> >> - Jorge Pereira
> >> On 28 May, 19:12, Roman Borschel <r.borsc...@gmx.net> wrote:
> >>> I only want to clarify what this discussion is about.
> >>> We have the Query class. It accepts full DQL strings. You can always
> >>> build any DQL query through string concatenation.
> >>> The issue with that is just that *conditional* query construction
> >>> (if
> >>> parameter A set condition X, if parameter B, set condition B OR C)
> >>> is cumbersome using string concatenation.
> >>> That is what the QueryBuilder class should be useful for.
> >>> And what we're now wondering is what the best and safest way is to
> >>> construct expressions with the QueryBuilder API.
> >>> It does add nothing in terms of functionality. Just a different
> >>> way to
> >>> construct queries that is more suitable if the construction is based
> >>> on conditions.
> >>> Regards
> >>> Roman
> >>> On May 28, 2009, at 7:58 PM, Adam Huttler wrote:
> >>>> Possibility #1 is the most expressive and easiest to read, IMO. I
> >>>> like the variant, even though it's more verbose, because it feels a
> >>>> little more flexible.
> >>>>> -----Original Message-----
> >>>>> From: doctrine-dev@googlegroups.com [mailto:doctrine-
> >>>>> dev@googlegroups.com] On Behalf Of Guilherme Blanco
> >>>>> Sent: Thursday, May 28, 2009 1:55 PM
> >>>>> To: doctrine-dev@googlegroups.com
> >>>>> Subject: [doctrine-dev] New DQL Criteria API
> >>>>> Hi guys,
> >>>>> We're talking a lot about Doctrine 2.0 and this time I'm coming
> >>>>> here
> >>>>> to talk about DQL changes.
> >>>>> String processing is something really weird, and we want to
> >>>>> remove,
> >>>>> since it's extremely error-prone.
> >>>>> Basically the purpose of this email is about WHERE conditions.
> >>>>> We end up with a lot of possibilities, and we want all of you to
> >>>> give
> >>>>> us suggestions about which way we should move to.
> >>>>> Here are the possibilities we came so far:
> >>>>>http://pastebin.com/f4f6c2aa0
> >>>>> If you have any other suggestions, include them here too.
> >>>>> We expect to find the simplest way to build a query without adding
> >>>> too
> >>>>> much WTF factor inside.
> Here's a wishlist, as a summary, sorted by perceived priority (imho):
> 1. Use option #3 as a base
> 2. Use ->or(), ->and()
> 3. Allow ->where('m.attr2', '=', '?')
> 4. Allow ->beginBlockIf(boolean)
> 5. Allow ->where(Expr::eq('m.attr2', '?'))
> 6. Allow ->in(Array)
> 7. Allow ->in()->beginBlock()->... subquery ... ->endBlock()
> Best regards,
> - Jorge Pereira
> On 28 May, 19:12, Roman Borschel <r.borsc...@gmx.net> wrote:
> > I only want to clarify what this discussion is about.
> > We have the Query class. It accepts full DQL strings. You can always
> > build any DQL query through string concatenation.
> > The issue with that is just that *conditional* query construction (if
> > parameter A set condition X, if parameter B, set condition B OR C)
> > is cumbersome using string concatenation.
> > That is what the QueryBuilder class should be useful for.
> > And what we're now wondering is what the best and safest way is to
> > construct expressions with the QueryBuilder API.
> > It does add nothing in terms of functionality. Just a different way to
> > construct queries that is more suitable if the construction is based
> > on conditions.
> > Regards
> > Roman
> > On May 28, 2009, at 7:58 PM, Adam Huttler wrote:
> > > Possibility #1 is the most expressive and easiest to read, IMO. I
> > > like the variant, even though it's more verbose, because it feels a
> > > little more flexible.
> > > > -----Original Message-----
> > > > From: doctrine-dev@googlegroups.com [mailto:doctrine-
> > > > dev@googlegroups.com] On Behalf Of Guilherme Blanco
> > > > Sent: Thursday, May 28, 2009 1:55 PM
> > > > To: doctrine-dev@googlegroups.com
> > > > Subject: [doctrine-dev] New DQL Criteria API
> > > > Hi guys,
> > > > We're talking a lot about Doctrine 2.0 and this time I'm coming here
> > > > to talk about DQL changes.
> > > > String processing is something really weird, and we want to remove,
> > > > since it's extremely error-prone.
> > > > Basically the purpose of this email is about WHERE conditions.
> > > > We end up with a lot of possibilities, and we want all of you to
> > > give
> > > > us suggestions about which way we should move to.
> > > > Here are the possibilities we came so far:
> > > >http://pastebin.com/f4f6c2aa0
> > > > If you have any other suggestions, include them here too.
> > > > We expect to find the simplest way to build a query without adding
> > > too
> > > > much WTF factor inside.
I'm agree that #1 way is the most flexible, expressive and readable.
I remember, some time ago there were lots of discussions on the same subject in the Propel's development mailing list. Don't know what became the final decision, but the original plan implied implementing Hibernate-like expressions. And that is the right way, IMO.
Obviously, Doctrine is already quite similar to Hibernate, and I think it's not a bad idea to copy mature and time proven solutions.
In addition, I have had some experience in implementing Criteria pattern, and have to say that expressions allow more abstraction that simplifies underlying RDBMS-specific layers.
On 29.05.2009, at 3:55, Guilherme Blanco wrote:
> We're talking a lot about Doctrine 2.0 and this time I'm coming here > to talk about DQL changes. > String processing is something really weird, and we want to remove, > since it's extremely error-prone.
> Basically the purpose of this email is about WHERE conditions. > We end up with a lot of possibilities, and we want all of you to give > us suggestions about which way we should move to. > Here are the possibilities we came so far: http://pastebin.com/f4f6c2aa0
> If you have any other suggestions, include them here too. > We expect to find the simplest way to build a query without adding too > much WTF factor inside.
@Eugene Do you have any idea on how to change #1 so that you can write
the query with the usual order, and not have to change the way you
think about queries? Also, how would you go about adding conditional
parts to a query? It seems that with this option you'd need to build
it all in one go, unlike with #3, but I may be missing something.
On 29 May, 09:15, Eugene Janusov <esy...@gmail.com> wrote:
> I'm agree that #1 way is the most flexible, expressive and readable.
> I remember, some time ago there were lots of discussions on the same
> subject in the Propel's development mailing list. Don't know what
> became the final decision, but the original plan implied implementing
> Hibernate-like expressions. And that is the right way, IMO.
> Obviously, Doctrine is already quite similar to Hibernate, and I think
> it's not a bad idea to copy mature and time proven solutions.
> In addition, I have had some experience in implementing Criteria
> pattern, and have to say that expressions allow more abstraction that
> simplifies underlying RDBMS-specific layers.
> On 29.05.2009, at 3:55, Guilherme Blanco wrote:
> > We're talking a lot about Doctrine 2.0 and this time I'm coming here
> > to talk about DQL changes.
> > String processing is something really weird, and we want to remove,
> > since it's extremely error-prone.
> > Basically the purpose of this email is about WHERE conditions.
> > We end up with a lot of possibilities, and we want all of you to give
> > us suggestions about which way we should move to.
> > Here are the possibilities we came so far:http://pastebin.com/f4f6c2aa0
> > If you have any other suggestions, include them here too.
> > We expect to find the simplest way to build a query without adding too
> > much WTF factor inside.
After a bit more thinking, I'd say that #3 and #4 aren't all that
different, and maybe #4 is even simpler (repeating "add" makes more
sense than repeating "where").
Still, I'd consider the following:
* It may be worth it to use ->and() and ->or() instead of relying on a
generic add with strings, even if that's what it actually does.
* If we're splitting query construction until each condition is a
method call, wouldn't it make sence to forget the ? and have ->add
('m.attr2', '=', $value)
* Why have a generic add and then use constants inside for
expressions? You could use a generic add() for those who like to use
strings, but have specific methods for clarity
> I finally made my final decision (it's not yet the official one of
> Doctrine)... I'd go with #4 variation.
> I was in doubt between #1 variant and #4 variant.
> About DQL as string support... we can include the support to this (in
> my personal decision):
> $w = Expr::where();
> $w->add(Expr::literal('m.attr1 = ?0 AND m.attr2 = ?1')) // WHERE
> m.attr1 = ?0 AND m.attr2 = ?1
> $q->add($w); // $q is instance of Query
> > I think that #2 and #3 are the best options for me. They are well
> > known from the 1.* branch, so it will be also easier to migrate.
> > I hope that it will be still possible to write conditions in the old way:
> > ->addWhere('(m.attr1 = ? AND (m.attr2 = ? OR m.attr2 = ?)) OR m.attr3
> > = ?', array($var, ...));
> > instead of separating each part of the condition into separate
> > parameter of where functions.
> > I like doctrine beacuse of the DQL it have. It is clear and very
> > similar to SQL.
> > ~
> > adrive
> > 2009/5/28 Roman Borschel <r.borsc...@gmx.net>:
> >> I only want to clarify what this discussion is about.
> >> We have the Query class. It accepts full DQL strings. You can always build
> >> any DQL query through string concatenation.
> >> The issue with that is just that *conditional* query construction (if
> >> parameter A set condition X, if parameter B, set condition B OR C)
> >> is cumbersome using string concatenation.
> >> That is what the QueryBuilder class should be useful for.
> >> And what we're now wondering is what the best and safest way is to construct
> >> expressions with the QueryBuilder API.
> >> It does add nothing in terms of functionality. Just a different way to
> >> construct queries that is more suitable if the construction is based on
> >> conditions.
> >> Regards
> >> Roman
> >> On May 28, 2009, at 7:58 PM, Adam Huttler wrote:
> >> Possibility #1 is the most expressive and easiest to read, IMO. I like the
> >> variant, even though it's more verbose, because it feels a little more
> >> flexible.
> >>> -----Original Message-----
> >>> From: doctrine-dev@googlegroups.com [mailto:doctrine-
> >>> dev@googlegroups.com] On Behalf Of Guilherme Blanco
> >>> Sent: Thursday, May 28, 2009 1:55 PM
> >>> To: doctrine-dev@googlegroups.com
> >>> Subject: [doctrine-dev] New DQL Criteria API
> >>> Hi guys,
> >>> We're talking a lot about Doctrine 2.0 and this time I'm coming here
> >>> to talk about DQL changes.
> >>> String processing is something really weird, and we want to remove,
> >>> since it's extremely error-prone.
> >>> Basically the purpose of this email is about WHERE conditions.
> >>> We end up with a lot of possibilities, and we want all of you to give
> >>> us suggestions about which way we should move to.
> >>> Here are the possibilities we came so far:
> >>>http://pastebin.com/f4f6c2aa0
> >>> If you have any other suggestions, include them here too.
> >>> We expect to find the simplest way to build a query without adding too
> >>> much WTF factor inside.
Any QueryBuilder API is practically useless if it's not good in
conditional query construction. Thats why I find many of the examples
that all construct a query in one go very misleading. Please consider
that.
> @Eugene Do you have any idea on how to change #1 so that you can write
> the query with the usual order, and not have to change the way you
> think about queries? Also, how would you go about adding conditional
> parts to a query? It seems that with this option you'd need to build
> it all in one go, unlike with #3, but I may be missing something.
> On 29 May, 09:15, Eugene Janusov <esy...@gmail.com> wrote:
>> I'm agree that #1 way is the most flexible, expressive and readable.
>> I remember, some time ago there were lots of discussions on the same
>> subject in the Propel's development mailing list. Don't know what
>> became the final decision, but the original plan implied implementing
>> Hibernate-like expressions. And that is the right way, IMO.
>> Obviously, Doctrine is already quite similar to Hibernate, and I
>> think
>> it's not a bad idea to copy mature and time proven solutions.
>> In addition, I have had some experience in implementing Criteria
>> pattern, and have to say that expressions allow more abstraction that
>> simplifies underlying RDBMS-specific layers.
>> On 29.05.2009, at 3:55, Guilherme Blanco wrote:
>>> We're talking a lot about Doctrine 2.0 and this time I'm coming here
>>> to talk about DQL changes.
>>> String processing is something really weird, and we want to remove,
>>> since it's extremely error-prone.
>>> Basically the purpose of this email is about WHERE conditions.
>>> We end up with a lot of possibilities, and we want all of you to
>>> give
>>> us suggestions about which way we should move to.
>>> Here are the possibilities we came so far:http://pastebin.com/f4f6c2aa0
>>> If you have any other suggestions, include them here too.
>>> We expect to find the simplest way to build a query without adding
>>> too
>>> much WTF factor inside.
And that's also why most of the examples here: http://pastebin.com/f4f6c2aa0 dont really show much, because which option is the shortest, most
readable, most concise there? Clear, the comment at the top! (// WHERE
(m.attr1 = ? AND (m.attr2 = ? OR m.attr2 = ?)) OR m.attr3 = ?)
I hope I made my point. I do not have a particular preference to
option #1, I am open to anything but please don't forget that the
resulting API should be especially good in conditional query
construction, not just the prettiest one out of mostly ugly solutions
to construct a query in one go. Because for that, a plain DQL string
can not be beaten.
Roman
On May 29, 2009, at 1:53 PM, Roman Borschel wrote:
> Any QueryBuilder API is practically useless if it's not good in
> conditional query construction. Thats why I find many of the examples
> that all construct a query in one go very misleading. Please consider
> that.
> Roman
> On May 29, 2009, at 1:32 PM, Jorge Pereira wrote:
>> @Eugene Do you have any idea on how to change #1 so that you can
>> write
>> the query with the usual order, and not have to change the way you
>> think about queries? Also, how would you go about adding conditional
>> parts to a query? It seems that with this option you'd need to build
>> it all in one go, unlike with #3, but I may be missing something.
>> On 29 May, 09:15, Eugene Janusov <esy...@gmail.com> wrote:
>>> I'm agree that #1 way is the most flexible, expressive and readable.
>>> I remember, some time ago there were lots of discussions on the same
>>> subject in the Propel's development mailing list. Don't know what
>>> became the final decision, but the original plan implied
>>> implementing
>>> Hibernate-like expressions. And that is the right way, IMO.
>>> Obviously, Doctrine is already quite similar to Hibernate, and I
>>> think
>>> it's not a bad idea to copy mature and time proven solutions.
>>> In addition, I have had some experience in implementing Criteria
>>> pattern, and have to say that expressions allow more abstraction
>>> that
>>> simplifies underlying RDBMS-specific layers.
>>> On 29.05.2009, at 3:55, Guilherme Blanco wrote:
>>>> We're talking a lot about Doctrine 2.0 and this time I'm coming
>>>> here
>>>> to talk about DQL changes.
>>>> String processing is something really weird, and we want to remove,
>>>> since it's extremely error-prone.
>>>> Basically the purpose of this email is about WHERE conditions.
>>>> We end up with a lot of possibilities, and we want all of you to
>>>> give
>>>> us suggestions about which way we should move to.
>>>> Here are the possibilities we came so far:http://pastebin.com/f4f6c2aa0
>>>> If you have any other suggestions, include them here too.
>>>> We expect to find the simplest way to build a query without adding
>>>> too
>>>> much WTF factor inside.
Yep, that is exactly what I've meant, and it is very similar to how it works in Hibernate (I, personally, will be even more happier with Hibernate's class names) and .NET's LINQ.
> Here is an example of conditional query construction with option #1 > http://pastie.org/493835
> Any QueryBuilder API is practically useless if it's not good in > conditional query construction. Thats why I find many of the examples > that all construct a query in one go very misleading. Please consider > that.
>> @Eugene Do you have any idea on how to change #1 so that you can >> write >> the query with the usual order, and not have to change the way you >> think about queries? Also, how would you go about adding conditional >> parts to a query? It seems that with this option you'd need to build >> it all in one go, unlike with #3, but I may be missing something.
The issue imho is that you loose all sense of order with that,
compared to a standard query. If PHP allowed you to define functions
as operators (eg, such as in Prolog or Lisp) it wouldn't be much of a
problem. But it's second nature to anyone familiar with SQL that an OR
takes a left and a right argument, which makes writing an expression
linear. With option #1, you're forcing the programmer to write queries
in an hierarchical manner, and you're adding visual noise with the
Expr:: prefix.
In option #1, how would you go about doing an OR between 3 variables?
Would Expr::or accept a variable number of arguments? If not, that's a
big fail right there - forcing the programmers to forgo a descriptive
language to adopt another way of structuring their queries.
Also, although beginBlockIf would be a good shortcut, it's not
necessarily a good idea to reinvent the wheel and build into the DQL
API the equivalent to PHP's standard control structures such as
complex 'if'. Still, an equivalent to what Roman Borschel suggests in
http://pastie.org/493835 would be http://pastebin.com/d2f414d3e
Please notice that either you make this simple and easy to read and
relate to standard SQL, or only the Anointed Ones will use it. :)
On 29 May, 13:00, Roman Borschel <r.borsc...@gmx.net> wrote:
> And that's also why most of the examples here:http://pastebin.com/f4f6c2aa0 > dont really show much, because which option is the shortest, most
> readable, most concise there? Clear, the comment at the top! (// WHERE
> (m.attr1 = ? AND (m.attr2 = ? OR m.attr2 = ?)) OR m.attr3 = ?)
> I hope I made my point. I do not have a particular preference to
> option #1, I am open to anything but please don't forget that the
> resulting API should be especially good in conditional query
> construction, not just the prettiest one out of mostly ugly solutions
> to construct a query in one go. Because for that, a plain DQL string
> can not be beaten.
> Roman
> On May 29, 2009, at 1:53 PM, Roman Borschel wrote:
> > Here is an example of conditional query construction with option #1
> > Any QueryBuilder API is practically useless if it's not good in
> > conditional query construction. Thats why I find many of the examples
> > that all construct a query in one go very misleading. Please consider
> > that.
> > Roman
> > On May 29, 2009, at 1:32 PM, Jorge Pereira wrote:
> >> @Eugene Do you have any idea on how to change #1 so that you can
> >> write
> >> the query with the usual order, and not have to change the way you
> >> think about queries? Also, how would you go about adding conditional
> >> parts to a query? It seems that with this option you'd need to build
> >> it all in one go, unlike with #3, but I may be missing something.
> >> On 29 May, 09:15, Eugene Janusov <esy...@gmail.com> wrote:
> >>> I'm agree that #1 way is the most flexible, expressive and readable.
> >>> I remember, some time ago there were lots of discussions on the same
> >>> subject in the Propel's development mailing list. Don't know what
> >>> became the final decision, but the original plan implied
> >>> implementing
> >>> Hibernate-like expressions. And that is the right way, IMO.
> >>> Obviously, Doctrine is already quite similar to Hibernate, and I
> >>> think
> >>> it's not a bad idea to copy mature and time proven solutions.
> >>> In addition, I have had some experience in implementing Criteria
> >>> pattern, and have to say that expressions allow more abstraction
> >>> that
> >>> simplifies underlying RDBMS-specific layers.
> >>> On 29.05.2009, at 3:55, Guilherme Blanco wrote:
> >>>> We're talking a lot about Doctrine 2.0 and this time I'm coming
> >>>> here
> >>>> to talk about DQL changes.
> >>>> String processing is something really weird, and we want to remove,
> >>>> since it's extremely error-prone.
> >>>> Basically the purpose of this email is about WHERE conditions.
> >>>> We end up with a lot of possibilities, and we want all of you to
> >>>> give
> >>>> us suggestions about which way we should move to.
> >>>> Here are the possibilities we came so far:http://pastebin.com/f4f6c2aa0
> >>>> If you have any other suggestions, include them here too.
> >>>> We expect to find the simplest way to build a query without adding
> >>>> too
> >>>> much WTF factor inside.
> The issue imho is that you loose all sense of order with that,
> compared to a standard query. If PHP allowed you to define functions
> as operators (eg, such as in Prolog or Lisp) it wouldn't be much of a
> problem. But it's second nature to anyone familiar with SQL that an OR
> takes a left and a right argument, which makes writing an expression
> linear. With option #1, you're forcing the programmer to write queries
> in an hierarchical manner, and you're adding visual noise with the
> Expr:: prefix.
> In option #1, how would you go about doing an OR between 3 variables?
> Would Expr::or accept a variable number of arguments? If not, that's a
> big fail right there - forcing the programmers to forgo a descriptive
> language to adopt another way of structuring their queries.
> Also, although beginBlockIf would be a good shortcut, it's not
> necessarily a good idea to reinvent the wheel and build into the DQL
> API the equivalent to PHP's standard control structures such as
> complex 'if'. Still, an equivalent to what Roman Borschel suggests inhttp://pastie.org/493835would behttp://pastebin.com/d2f414d3e
> Please notice that either you make this simple and easy to read and
> relate to standard SQL, or only the Anointed Ones will use it. :)
> On 29 May, 13:00, Roman Borschel <r.borsc...@gmx.net> wrote:
> > And that's also why most of the examples here:http://pastebin.com/f4f6c2aa0 > > dont really show much, because which option is the shortest, most
> > readable, most concise there? Clear, the comment at the top! (// WHERE
> > (m.attr1 = ? AND (m.attr2 = ? OR m.attr2 = ?)) OR m.attr3 = ?)
> > I hope I made my point. I do not have a particular preference to
> > option #1, I am open to anything but please don't forget that the
> > resulting API should be especially good in conditional query
> > construction, not just the prettiest one out of mostly ugly solutions
> > to construct a query in one go. Because for that, a plain DQL string
> > can not be beaten.
> > Roman
> > On May 29, 2009, at 1:53 PM, Roman Borschel wrote:
> > > Here is an example of conditional query construction with option #1
> > > Any QueryBuilder API is practically useless if it's not good in
> > > conditional query construction. Thats why I find many of the examples
> > > that all construct a query in one go very misleading. Please consider
> > > that.
> > > Roman
> > > On May 29, 2009, at 1:32 PM, Jorge Pereira wrote:
> > >> @Eugene Do you have any idea on how to change #1 so that you can
> > >> write
> > >> the query with the usual order, and not have to change the way you
> > >> think about queries? Also, how would you go about adding conditional
> > >> parts to a query? It seems that with this option you'd need to build
> > >> it all in one go, unlike with #3, but I may be missing something.
> > >> On 29 May, 09:15, Eugene Janusov <esy...@gmail.com> wrote:
> > >>> I'm agree that #1 way is the most flexible, expressive and readable.
> > >>> I remember, some time ago there were lots of discussions on the same
> > >>> subject in the Propel's development mailing list. Don't know what
> > >>> became the final decision, but the original plan implied
> > >>> implementing
> > >>> Hibernate-like expressions. And that is the right way, IMO.
> > >>> Obviously, Doctrine is already quite similar to Hibernate, and I
> > >>> think
> > >>> it's not a bad idea to copy mature and time proven solutions.
> > >>> In addition, I have had some experience in implementing Criteria
> > >>> pattern, and have to say that expressions allow more abstraction
> > >>> that
> > >>> simplifies underlying RDBMS-specific layers.
> > >>> On 29.05.2009, at 3:55, Guilherme Blanco wrote:
> > >>>> We're talking a lot about Doctrine 2.0 and this time I'm coming
> > >>>> here
> > >>>> to talk about DQL changes.
> > >>>> String processing is something really weird, and we want to remove,
> > >>>> since it's extremely error-prone.
> > >>>> Basically the purpose of this email is about WHERE conditions.
> > >>>> We end up with a lot of possibilities, and we want all of you to
> > >>>> give
> > >>>> us suggestions about which way we should move to.
> > >>>> Here are the possibilities we came so far:http://pastebin.com/f4f6c2aa0
> > >>>> If you have any other suggestions, include them here too.
> > >>>> We expect to find the simplest way to build a query without adding
> > >>>> too
> > >>>> much WTF factor inside.
On Fri, May 29, 2009 at 4:12 PM, Fixe <tiago.ribe...@gmail.com> wrote:
> +1 for Jorge Pereira approach.
> On 29 May, 15:06, Jorge Pereira <jpereira...@gmail.com> wrote:
> > Hi,
> > The issue imho is that you loose all sense of order with that,
> > compared to a standard query. If PHP allowed you to define functions
> > as operators (eg, such as in Prolog or Lisp) it wouldn't be much of a
> > problem. But it's second nature to anyone familiar with SQL that an OR
> > takes a left and a right argument, which makes writing an expression
> > linear. With option #1, you're forcing the programmer to write queries
> > in an hierarchical manner, and you're adding visual noise with the
> > Expr:: prefix.
> > In option #1, how would you go about doing an OR between 3 variables?
> > Would Expr::or accept a variable number of arguments? If not, that's a
> > big fail right there - forcing the programmers to forgo a descriptive
> > language to adopt another way of structuring their queries.
> > Also, although beginBlockIf would be a good shortcut, it's not
> > necessarily a good idea to reinvent the wheel and build into the DQL
> > API the equivalent to PHP's standard control structures such as
> > complex 'if'. Still, an equivalent to what Roman Borschel suggests
> inhttp://pastie.org/493835would behttp://pastebin.com/d2f414d3e
> > Please notice that either you make this simple and easy to read and
> > relate to standard SQL, or only the Anointed Ones will use it. :)
> > On 29 May, 13:00, Roman Borschel <r.borsc...@gmx.net> wrote:
> > > And that's also why most of the examples here:
> http://pastebin.com/f4f6c2aa0 > > > dont really show much, because which option is the shortest, most
> > > readable, most concise there? Clear, the comment at the top! (// WHERE
> > > (m.attr1 = ? AND (m.attr2 = ? OR m.attr2 = ?)) OR m.attr3 = ?)
> > > I hope I made my point. I do not have a particular preference to
> > > option #1, I am open to anything but please don't forget that the
> > > resulting API should be especially good in conditional query
> > > construction, not just the prettiest one out of mostly ugly solutions
> > > to construct a query in one go. Because for that, a plain DQL string
> > > can not be beaten.
> > > Roman
> > > On May 29, 2009, at 1:53 PM, Roman Borschel wrote:
> > > > Here is an example of conditional query construction with option #1
> > > > Any QueryBuilder API is practically useless if it's not good in
> > > > conditional query construction. Thats why I find many of the examples
> > > > that all construct a query in one go very misleading. Please consider
> > > > that.
> > > > Roman
> > > > On May 29, 2009, at 1:32 PM, Jorge Pereira wrote:
> > > >> @Eugene Do you have any idea on how to change #1 so that you can
> > > >> write
> > > >> the query with the usual order, and not have to change the way you
> > > >> think about queries? Also, how would you go about adding conditional
> > > >> parts to a query? It seems that with this option you'd need to build
> > > >> it all in one go, unlike with #3, but I may be missing something.
> > > >> On 29 May, 09:15, Eugene Janusov <esy...@gmail.com> wrote:
> > > >>> I'm agree that #1 way is the most flexible, expressive and
> readable.
> > > >>> I remember, some time ago there were lots of discussions on the
> same
> > > >>> subject in the Propel's development mailing list. Don't know what
> > > >>> became the final decision, but the original plan implied
> > > >>> implementing
> > > >>> Hibernate-like expressions. And that is the right way, IMO.
> > > >>> Obviously, Doctrine is already quite similar to Hibernate, and I
> > > >>> think
> > > >>> it's not a bad idea to copy mature and time proven solutions.
> > > >>> In addition, I have had some experience in implementing Criteria
> > > >>> pattern, and have to say that expressions allow more abstraction
> > > >>> that
> > > >>> simplifies underlying RDBMS-specific layers.
> > > >>> On 29.05.2009, at 3:55, Guilherme Blanco wrote:
> > > >>>> We're talking a lot about Doctrine 2.0 and this time I'm coming
> > > >>>> here
> > > >>>> to talk about DQL changes.
> > > >>>> String processing is something really weird, and we want to
> remove,
> > > >>>> since it's extremely error-prone.
> > > >>>> Basically the purpose of this email is about WHERE conditions.
> > > >>>> We end up with a lot of possibilities, and we want all of you to
> > > >>>> give
> > > >>>> us suggestions about which way we should move to.
> > > >>>> Here are the possibilities we came so far:
> http://pastebin.com/f4f6c2aa0
> > > >>>> If you have any other suggestions, include them here too.
> > > >>>> We expect to find the simplest way to build a query without adding
> > > >>>> too
> > > >>>> much WTF factor inside.
> In option #1, how would you go about doing an OR between 3 variables? > Would Expr::or accept a variable number of arguments?
I think it's acceptable to use var-arg for Expr::or, but there is no such thing as "OR between 3 variables". OR is a binary operator, and the order in which conditions are evaluated is significant.
> Also, although beginBlockIf would be a good shortcut, it's not > necessarily a good idea to reinvent the wheel and build into the DQL > API the equivalent to PHP's standard control structures such as > complex 'if'. Still, an equivalent to what Roman Borschel suggests in > http://pastie.org/493835 would be http://pastebin.com/d2f414d3e
PHP's control structures are а matter of PHP's interpreter, and who will be responsible for such things:
I have to say that I really don't like cluttering the API with basic
control structures (if/then/else/...)
It looks unnatural and is really an abuse of fluent interfaces in my
eyes.
> +1 too, I really think it's the best way to build complex queries
> easily.
> On Fri, May 29, 2009 at 4:12 PM, Fixe <tiago.ribe...@gmail.com> wrote:
> +1 for Jorge Pereira approach.
> On 29 May, 15:06, Jorge Pereira <jpereira...@gmail.com> wrote:
> > Hi,
> > The issue imho is that you loose all sense of order with that,
> > compared to a standard query. If PHP allowed you to define functions
> > as operators (eg, such as in Prolog or Lisp) it wouldn't be much
> of a
> > problem. But it's second nature to anyone familiar with SQL that
> an OR
> > takes a left and a right argument, which makes writing an expression
> > linear. With option #1, you're forcing the programmer to write
> queries
> > in an hierarchical manner, and you're adding visual noise with the
> > Expr:: prefix.
> > In option #1, how would you go about doing an OR between 3
> variables?
> > Would Expr::or accept a variable number of arguments? If not,
> that's a
> > big fail right there - forcing the programmers to forgo a
> descriptive
> > language to adopt another way of structuring their queries.
> > Also, although beginBlockIf would be a good shortcut, it's not
> > necessarily a good idea to reinvent the wheel and build into the DQL
> > API the equivalent to PHP's standard control structures such as
> > complex 'if'. Still, an equivalent to what Roman Borschel suggests
> inhttp://pastie.org/493835would behttp://pastebin.com/d2f414d3e
> > Please notice that either you make this simple and easy to read and
> > relate to standard SQL, or only the Anointed Ones will use it. :)
> > On 29 May, 13:00, Roman Borschel <r.borsc...@gmx.net> wrote:
> > > And that's also why most of the examples here:http://pastebin.com/f4f6c2aa0 > > > dont really show much, because which option is the shortest,
> most
> > > readable, most concise there? Clear, the comment at the top! (//
> WHERE
> > > (m.attr1 = ? AND (m.attr2 = ? OR m.attr2 = ?)) OR m.attr3 = ?)
> > > I hope I made my point. I do not have a particular preference to
> > > option #1, I am open to anything but please don't forget that the
> > > resulting API should be especially good in conditional query
> > > construction, not just the prettiest one out of mostly ugly
> solutions
> > > to construct a query in one go. Because for that, a plain DQL
> string
> > > can not be beaten.
> > > Roman
> > > On May 29, 2009, at 1:53 PM, Roman Borschel wrote:
> > > > Here is an example of conditional query construction with
> option #1
> > > > Any QueryBuilder API is practically useless if it's not good in
> > > > conditional query construction. Thats why I find many of the
> examples
> > > > that all construct a query in one go very misleading. Please
> consider
> > > > that.
> > > > Roman
> > > > On May 29, 2009, at 1:32 PM, Jorge Pereira wrote:
> > > >> @Eugene Do you have any idea on how to change #1 so that you
> can
> > > >> write
> > > >> the query with the usual order, and not have to change the
> way you
> > > >> think about queries? Also, how would you go about adding
> conditional
> > > >> parts to a query? It seems that with this option you'd need
> to build
> > > >> it all in one go, unlike with #3, but I may be missing
> something.
> > > >> On 29 May, 09:15, Eugene Janusov <esy...@gmail.com> wrote:
> > > >>> I'm agree that #1 way is the most flexible, expressive and
> readable.
> > > >>> I remember, some time ago there were lots of discussions on
> the same
> > > >>> subject in the Propel's development mailing list. Don't know
> what
> > > >>> became the final decision, but the original plan implied
> > > >>> implementing
> > > >>> Hibernate-like expressions. And that is the right way, IMO.
> > > >>> Obviously, Doctrine is already quite similar to Hibernate,
> and I
> > > >>> think
> > > >>> it's not a bad idea to copy mature and time proven solutions.
> > > >>> In addition, I have had some experience in implementing
> Criteria
> > > >>> pattern, and have to say that expressions allow more
> abstraction
> > > >>> that
> > > >>> simplifies underlying RDBMS-specific layers.
> > > >>> On 29.05.2009, at 3:55, Guilherme Blanco wrote:
> > > >>>> We're talking a lot about Doctrine 2.0 and this time I'm
> coming
> > > >>>> here
> > > >>>> to talk about DQL changes.
> > > >>>> String processing is something really weird, and we want to
> remove,
> > > >>>> since it's extremely error-prone.
> > > >>>> Basically the purpose of this email is about WHERE
> conditions.
> > > >>>> We end up with a lot of possibilities, and we want all of
> you to
> > > >>>> give
> > > >>>> us suggestions about which way we should move to.
> > > >>>> Here are the possibilities we came so far:http://pastebin.com/f4f6c2aa0
> > > >>>> If you have any other suggestions, include them here too.
> > > >>>> We expect to find the simplest way to build a query without
> adding
> > > >>>> too
> > > >>>> much WTF factor inside.
I agree with Roman. PHP already has control structures on a language
level. These feel very awkward to me.
From: doctrine-dev@googlegroups.com [mailto:doctrine-dev@googlegroups.com]
On Behalf Of Roman Borschel
Sent: Friday, May 29, 2009 11:27 AM
To: doctrine-dev@googlegroups.com
Subject: [doctrine-dev] Re: New DQL Criteria API
I have to say that I really don't like cluttering the API with basic
control structures (if/then/else/...)
It looks unnatural and is really an abuse of fluent interfaces in my eyes.
Roman
On May 29, 2009, at 4:32 PM, Colin Darie wrote:
+1 too, I really think it's the best way to build complex queries easily.
On Fri, May 29, 2009 at 4:12 PM, Fixe <tiago.ribe...@gmail.com> wrote:
+1 for Jorge Pereira approach.
On 29 May, 15:06, Jorge Pereira <jpereira...@gmail.com> wrote:
> The issue imho is that you loose all sense of order with that,
> compared to a standard query. If PHP allowed you to define functions
> as operators (eg, such as in Prolog or Lisp) it wouldn't be much of a
> problem. But it's second nature to anyone familiar with SQL that an OR
> takes a left and a right argument, which makes writing an expression
> linear. With option #1, you're forcing the programmer to write queries
> in an hierarchical manner, and you're adding visual noise with the
> Expr:: prefix.
> In option #1, how would you go about doing an OR between 3 variables?
> Would Expr::or accept a variable number of arguments? If not, that's a
> big fail right there - forcing the programmers to forgo a descriptive
> language to adopt another way of structuring their queries.
> Also, although beginBlockIf would be a good shortcut, it's not
> necessarily a good idea to reinvent the wheel and build into the DQL
> API the equivalent to PHP's standard control structures such as
> complex 'if'. Still, an equivalent to what Roman Borschel suggests
> > dont really show much, because which option is the shortest, most
> > readable, most concise there? Clear, the comment at the top! (// WHERE
> > (m.attr1 = ? AND (m.attr2 = ? OR m.attr2 = ?)) OR m.attr3 = ?)
> > I hope I made my point. I do not have a particular preference to
> > option #1, I am open to anything but please don't forget that the
> > resulting API should be especially good in conditional query
> > construction, not just the prettiest one out of mostly ugly solutions
> > to construct a query in one go. Because for that, a plain DQL string
> > can not be beaten.
> > Roman
> > On May 29, 2009, at 1:53 PM, Roman Borschel wrote:
> > > Here is an example of conditional query construction with option #1
> > > Any QueryBuilder API is practically useless if it's not good in
> > > conditional query construction. Thats why I find many of the
examples
> > > that all construct a query in one go very misleading. Please
consider
> > > that.
> > > Roman
> > > On May 29, 2009, at 1:32 PM, Jorge Pereira wrote:
> > >> @Eugene Do you have any idea on how to change #1 so that you can
> > >> write
> > >> the query with the usual order, and not have to change the way you
> > >> think about queries? Also, how would you go about adding
conditional
> > >> parts to a query? It seems that with this option you'd need to
build
> > >> it all in one go, unlike with #3, but I may be missing something.
> > >> On 29 May, 09:15, Eugene Janusov <esy...@gmail.com> wrote:
> > >>> I'm agree that #1 way is the most flexible, expressive and
readable.
> > >>> I remember, some time ago there were lots of discussions on the
same
> > >>> subject in the Propel's development mailing list. Don't know what
> > >>> became the final decision, but the original plan implied
> > >>> implementing
> > >>> Hibernate-like expressions. And that is the right way, IMO.
> > >>> Obviously, Doctrine is already quite similar to Hibernate, and I
> > >>> think
> > >>> it's not a bad idea to copy mature and time proven solutions.
> > >>> In addition, I have had some experience in implementing Criteria
> > >>> pattern, and have to say that expressions allow more abstraction
> > >>> that
> > >>> simplifies underlying RDBMS-specific layers.
> > >>> On 29.05.2009, at 3:55, Guilherme Blanco wrote:
> > >>>> We're talking a lot about Doctrine 2.0 and this time I'm coming
> > >>>> here
> > >>>> to talk about DQL changes.
> > >>>> String processing is something really weird, and we want to
remove,
> > >>>> since it's extremely error-prone.
> > >>>> Basically the purpose of this email is about WHERE conditions.
> > >>>> We end up with a lot of possibilities, and we want all of you to
> > >>>> give
> > >>>> us suggestions about which way we should move to.
> > >>>> Here are the possibilities we came so
> > >>>> If you have any other suggestions, include them here too.
> > >>>> We expect to find the simplest way to build a query without
adding
> > >>>> too
> > >>>> much WTF factor inside.
|
