https://bugs.freedesktop.org/show_bug.cgi?id=64177
Patrick Ohly <[email protected]> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |NEEDINFO Priority|highest |medium Assignee|[email protected] |syncevolution-issues@syncev | |olution.org --- Comment #8 from Patrick Ohly <[email protected]> --- Enhanced searching is in master, see: commit 236a89fd86dec0bf77f1cd00ca767695f31b8889 Author: Patrick Ohly <[email protected]> Date: Tue May 28 16:25:19 2013 +0200 PIM: document enhanced searching (search part of FDO #64177) Documents 'or', 'and' and new per-field 'is|contains|begins_with|ends_with' operations. commit 34241881ae10b0bc24038ddbb7b53979e8825b28 Author: Patrick Ohly <[email protected]> Date: Tue May 28 22:55:26 2013 +0200 PIM testing: test field tests doFilter() gets extended to take (<full name>, <vcard>) tuples in addition to the full name alone. Then this is used to create one large vCard that is suitable for testing (field content unique, all fields set, etc.) with various filters. All field tests are covered with at least one positive and one negative case. commit c922aed0f2ccb0ddcec969f4384e878ca3859385 Author: Patrick Ohly <[email protected]> Date: Tue May 28 22:51:48 2013 +0200 PIM: implement 'is/contains/begins-with/ends-with' The operation is a runtime parameter of different classes, whereas extracting the right values to compare via the operation is hard-coded at compile time. This is a rather arbitrary compromise between code duplication, simplicity and performance (which, in fact, was not measured at all). The code for selecting case-sensitivity and the normalization before the string operations is shared with the older 'any-contains' operation. commit 3796f3cdde544e54fa2190e8029889c3b9c4ffc4 Author: Patrick Ohly <[email protected]> Date: Tue May 28 16:27:37 2013 +0200 PIM testing: test case for 'and' and 'or' The new TestContacts.testFilterLogic uses the same infrastructure as the language tests and covers some combinations of 'and' and 'or'. In some cases, Python lists had to be avoided in favor of tuples, because Python cannot automatically map the lists to a 'av' array of variants, while sending a tuple enumerating its types can be sent and gets accepted by PIM Manager. commit b42e093a608c367b118ecc5844a0018a978516fb Author: Patrick Ohly <[email protected]> Date: Tue May 28 16:26:45 2013 +0200 PIM: implement 'and' and 'or' Implementation falls naturally into the new framework, with special logic filters combining the results of sub-filters. commit 9942cecd8435a2b1e9602aa1b4d21be19240eef9 Author: Patrick Ohly <[email protected]> Date: Tue May 28 15:22:58 2013 +0200 PIM: support recursive search filter This changes the signature of the filter parameter in Search(), RefineSearch() and ReplaceSearch() from 'as' (array of strings) to 'av' (array of variants). Allowed entries in the variant are arrays containing strings and/or other such arrays (recursive!). A single string as value is not supported, which is the reason why 'av' instead of just plain 'v' makes sense (mismatches can already be found in the sender, potentially at compile time). It also helps Python choose the right type when asked to send an empty list. When just using 'v', Python cannot decide automatically. Error messages include a backtrace of all terms that the current, faulty term was included in. That helps to locate the error in a potentially larger filter. The scope of supported searches has not changed (yet). commit 4a617c1cc98e7d85f020d35860f09647443e147c Author: Patrick Ohly <[email protected]> Date: Tue May 28 15:13:00 2013 +0200 GDBus GIO: support recursive variant with one type The signature of the new type is just a 'v' for variant. Recursion is only supported in combination with std::vector. This is done to keep implementation simpler. std::vector was chosen over other collections because it is easier to work with in method calls, the main purpose of the new type. The conversion from D-Bus messages accepts anything which can be mapped into the variant: arrays, tuples, plain types, and of course variants containing those. This helps with backward compatibility (one can turn an interface which took a fixed type like std::vector<std::string> into something with a recursive variant) and with Python, because Python sends arrays and tuples without converting into variants when the app uses those simpler types. One caveat exists with sending an empty list in Python: when using 'v' as signature in the interface, Python doesn't know how to send the empty list without assistance by the programmer (as in dbus.Array([], signature='s'). If possible, avoid the plain 'v' in an interface in favor of something like 'av' (= std::vector<boost::variant>). This should resolve enhanced searching. Enhanced sorting is still open, but less important and still undefined -> lowering priority and deferring it. -- You are receiving this mail because: You are on the CC list for the bug. You are the assignee for the bug.
_______________________________________________ Syncevolution-issues mailing list [email protected] https://lists.syncevolution.org/mailman/listinfo/syncevolution-issues
