https://bugs.freedesktop.org/show_bug.cgi?id=46480

Lionel Elie Mamane <[email protected]> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         AssignedTo|[email protected] |[email protected]
                   |desktop.org                 |

--- Comment #20 from Lionel Elie Mamane <[email protected]> 2012-08-21 13:36:40 
UTC ---
(In reply to comment #16)

> We double up with the
> because the sValue has already been quoted from a previous getPredicateValue
> from
> http://opengrok.libreoffice.org/xref/core/dbaccess/source/ui/dlg/queryfilter.cxx#360

> @lionel would such heuristics work or is there a better 'real' solution

> [*] some checking if sValue starts with '{' and ends with '}' or starts with
> '{D' and ends with '}'

My testing shows that one will there see the database-specific date format:

1) for ODBC it will be as you described
2) for PostgreSQL-SDBC 'YYYY-MM-DD'
3) for embedded HSQLDB, it will be #DD/MM/YYY# (or is it #MM/DD/YYYY#? Not
sure)


The whole structure of that code is mightily weird:

It will parse the string (putting a ColumnName = Value, even if the operator is
not =, but e.g. >=), only to convert it back to a string again (just the Value
part). Not sure why that is. Is this intended as some kind of canonicalisation?
These functions clearly expect already canonicalised data, so <shrug>. One also
clearly sees in the UI that the data is canonicalised on entry, immediately
after focus moves out of the text entry area.

The value is always treated as a string instead of keeping its native type (it
is an Any! you can shove a date in there!), which smells fishy.

I'm trying very hard to find a way to touch this mess without completely
rewriting it, in a way that would be OK for the stable branch.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
_______________________________________________
Libreoffice-bugs mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs

Reply via email to