-----Message d'origine-----
De : Peter Rabbitson
Envoy? : lundi, 18. mai 2009 15:28
Hi everyone,
With SQLA 2.0 coming closer to reality, there was a substantial effort
to clear up and disambiguate the SQLA 1.x API. One of the remaining
quirks is the -nest operator, which was introduced in version 1.18.
The examples provided in the documentation make no sense from a
usability point of view, as all of them are more clearly expressed
by other means.
[examples cut]
The development team of SQLA 2.0 would like to know if there are
real-world -nest usages which can not be easily expressed in any
other ways. If this is not the case, -nest will be marked as
deprecated by a warning starting with the next SQLA version, and
will be completely removed in 2.0.
Any input/thoughts welcome!
De : Peter Rabbitson
Envoy? : lundi, 18. mai 2009 15:28
Hi everyone,
With SQLA 2.0 coming closer to reality, there was a substantial effort
to clear up and disambiguate the SQLA 1.x API. One of the remaining
quirks is the -nest operator, which was introduced in version 1.18.
The examples provided in the documentation make no sense from a
usability point of view, as all of them are more clearly expressed
by other means.
[examples cut]
The development team of SQLA 2.0 would like to know if there are
real-world -nest usages which can not be easily expressed in any
other ways. If this is not the case, -nest will be marked as
deprecated by a warning starting with the next SQLA version, and
will be completely removed in 2.0.
Any input/thoughts welcome!
As far as I understand, when NWIGER originally introduced the -nest operator, this was the recommended way for nesting several ANDs/ORs. The advantage of that approach was that the motto "hashrefs are ANDs, arrayrefs are ORs" was consistent through the whole syntax tree. Also, it was quite convenient to merge several sets of constraints with something like
my $new_constraints = {col1 => $v1, col2 => $v2, -nest => $original_constraints};
where $original_constraints can be either a hashref or an arrayref, you don't care.
Now the recommended way for nesting several ANDs/ORs is
-and => {..} | [..], -or => {..} | [..]
Personnally I preferred the old way, because now the semantics of a (hash|array)ref depends on its outside context. This can be more complex to read, and one must be a little careful when merging several sets of constraints. But never mind, I agree that the new way has the same expressive power: anything that was expressed with -nest can also be done with -and/-or. And since the -and/-or syntax has been used for many years by the DBIC community, which is probably the biggest user base for SQLA, that's definitely the way to go.
Deprecating -nest might have a negative impact on SQLA users outside of the DBIC community; but it's hard to tell how many people would be affected. As far as our Geneva team is concerned, replacing all -nest calls in our applications is not a big problem.
Cheers,
Laurent Dami
