On Wed, Jul 15, 2009 at 11:44:56AM +0000, Tobias wrote:

I'm trying to get to the facts of what currently is possible and implemented.
See below.

> Ralf Schlatterbeck schrieb:
> > I've repeatedly said that -- since the comma should be a decimal comma
> > too, I DO NOT WANT the comma to mean "or".
> 
> But you know that we *need* to support things like
> 
>   2, 5

NO WE DON'T.
I'm currently getting -- If I'm entering that into the query-form for an
integer AND PLEASE NOTE THAT AN ID IS NOT AN INTEGER:

psycopg.ProgrammingError: ERROR: invalid input syntax for type real: "0.5, 0.7" select
_user.id,lower(_user._lastname),(lower(_user._lastname) is not NULL) from _user where ((_user._status in ('1'))) and
_user._lunch_duration='0.5, 0.7' and _user.__retired__ <> 1 order by (lower(_user._lastname) is not
NULL),lower(_user._lastname),_user.id

When entering "0.5, 0.7" into the search form in one of the running
trackers I have (with heavily customized schema).

> because they are supported currently for ids and integers.

FOR IDs yes but FOR INTEGERS NO and my proposal states that IDs should
be left alone for the moment

So please accept that you were *WRONG* concerning what
backward-compatibility requirements we have.

> > Same for blank. I DO NOT WANT a space to implicitly mean "or".
> 
> You know that we *need* to support the space, because thinks like
> 
>   2 5
> 
> are supported for ids.

I've repeatedly stated that IDS ARE STRINGS IN THE CURRENT
IMPLEMENTATION. This IS CONSIDERED A BUG. But one that is very hard to
fix without breaking a lot of things for a lot of people.

> Both cases are important for compatibility, and you don't mention them
> in your proposal.  In fact, what you intend to do is to *break*
> compatibility for very common and convenient search expressions.

See above. YOU are the one who is wrong.

> > If you see ranges as things that can contain just one number (as it is
> > currently implemented in roundup.date.Range) you won't need the sets.
> 
> Why would I want to see ranges like that? Ranges have limits, not members!

come on. think mathematically. A range with a zero-length inclusive
interval is the same as a number.

> There is a reason for this implementation:  Roundup supports non-SQL
> backends.  If it wouldn't, we would have supported date searches right
> away using
> 
>   WHERE DATE(fieldname) = date1
> 
> and inclusive range searches using
> 
>   WHERE DATE(fieldname) BETWEEN date1 AND date2

One of the reasons why roundup has implemented its own query-syntax is
that its easier for users than writing sql. Otherwise we could have used
one of the many sql parsers out there to implement sql-queries for other
backends.

> Instead of generally impacting Roundup's search facilities it would have
> been better do date range searches the SQL way and teach the non-SQL
> backend to extract the date component from a datetime value.

My proposal does not limit the search facilities. It achieves the same
as your proposal with 
- less syntactic constructs
- easier expression syntax
- full backward compatibility
- easier to implement and maintain

> Maybe you are too deeply involved in the Roundup code to be able to take
> up an ordinary user's viewpoint.

Thats not an argument but a personal attack.

> > Zen of Python:
> > Beautiful is better than ugly
> 
> Well, concerning curly braces, this is surely a matter of taste.
> I like them.

I don't -- especially since I've proved that we don't need them.

> > Readability counts
> 
> Sets with curly brackets are /very/ readable!

Which, again, is a question of viewpoint.

> And surely,
> 
>   {1, 2, 5} or [10;20]
> 
> is very much better readable than
> 
>   1 or 2 or 5 or 10; 20

Huh?

See for example the next guideline.

> 
> > There should be one-- and preferably only one --obvious way to do it
> 
> /preferably/ only one /obvious/ way.
> 
> But we *must* already support several ways, e.g. because of the existing
> date range syntax.

No. See above about the backward compatibility arguments.

> > If the implementation is hard to explain, it's a bad idea
> 
> I /have/ explained my concept, and it wasn't hard at all.

explaining is something that requires understanding on the receiver
side, otherwise it fails.

Yes.

Huh?
If you mean by "expressiveness" that there are several ways to formulate
the same thing I'd answer with
"There should be one-- and preferably only one --obvious way to do it"

See above. Neither comma nor space is currently supported for integers
or dates.

I don't. Read my proposal and the discussion at the end.

That would be left for a future bugfix.

They are strings. I've done some patches to at least provide for proper
sorting (some years ago). But this remains a bug in roundup. Patches
that don't break a lot for a lot of people are welcome.
And note that I do *not* intend to apply the new range-search operations
to IDs for the moment.

patches are welcome.

patches are welcome.

I don't think so, otherwise searches in SQL are not possible. But if you
have a good idea provide a patch.

Ralf
-- 
Dr. Ralf Schlatterbeck                  Tel:   +43/2243/26465-16
Open Source Consulting                  Fax:   +43/2243/26465-23
Reichergasse 131                        www:   http://www.runtux.com
A-3411 Weidling                         email: office@runtux.com
osAlliance member                       email: rsc@osalliance.com