Difference between revisions of "Features/Plain Query Format"
(→Benefit to Sugar: another to two SAMs were launched..) |
|||
| Line 23: | Line 23: | ||
== Detailed Description == | == Detailed Description == | ||
| − | Instead of having complicated query format for org.laptop.sugar.DataStore::find(), use plain string [http://www.xapian.org/docs/queryparser.html full featured] query format i.e. use all system query parameters(like timestamp, mime_type etc.) in query string(from former find()'s 'query' argument). | + | Instead of having complicated query format for org.laptop.sugar.DataStore::find(), use plain string of [http://www.xapian.org/docs/queryparser.html full featured] query format i.e. use all system query parameters(like timestamp, mime_type etc.) in query string(from former find()'s 'query' argument). |
All system, users predefined and some(its up to user) of users query terms | All system, users predefined and some(its up to user) of users query terms | ||
Revision as of 15:57, 17 July 2009
Summary
Provide simple string query format for Datastore find() method to cover all kinds of requests.
Owner
- Name: Aleksey Lim
- Email: send an email
Current status
- Targeted release: 0.86
- Last updated: Fri Jul 17 06:34:13 UTC 2009
- Percentage of completion: 0%
Detailed Description
Instead of having complicated query format for org.laptop.sugar.DataStore::find(), use plain string of full featured query format i.e. use all system query parameters(like timestamp, mime_type etc.) in query string(from former find()'s 'query' argument).
All system, users predefined and some(its up to user) of users query terms
- use prefixes like mime_type:"text/plain", author:Strugatsky etc.
- could be ranged e.g. timestamp:<stamp1>..<stamp2>
- could be sorted
System terms
| Datastore field | Flags/Parameters | Notes |
|---|---|---|
| tree_id | ||
| version_id | ||
| parent_id | ||
| ctime | ranged sorted | |
| bundle_id | ||
| entry_type | ||
| creator | ||
| mime_type | ||
| title | sorted | |
| activity_id | ||
| timestamp | ranged sorted | |
| keep | ||
| filesize | ranged sorted | TODO: propose adding this field to DS |
| participant | sorted | TODO: propose adding this field to DS |
| buddies_count | sorted | (?) |
Users predefined terms
| Datastore field | Flags/Parameters | Notes |
|---|---|---|
| artist | sorted | |
| album | sorted | |
| author | sorted | and composer as well |
| date | ranged sorted | |
| genre | sorted | |
| track_number | ranged sorted | |
| track_count | ranged sorted | |
| disc_number | ranged sorted | |
| disc_count | ranged sorted | |
| copyright | sorted |
Another ways to differentiate DS objects
All metadata fields will be tracked as usual, so regular search(w/o prefixes) should work. There is only one addition - optional prefixes in tags field.
All substrings(tags) from tags field in format:
- <substring_w/o_separators>:<string_w/o_separators_after_:>
- <substring_w/o_separators>:"<string_w/o_separators_after_: but with separators inside string>"
Will be treated as tags with prefix, so user can type in search bar:
- books:favorite if tags has substring books:favorite
- books:brothers if tags has substring books:"The Strugatsky brothers"
Benefit to Sugar
- simple(plain string in comparing with existed API with dictionary find()'s argument) query format for dbus find() method
- simple and new-feature-proof way to implement find method for example in CLI tools(because this tool needs only to pass plain string to Datastore service)
- let experienced users make complicated search in Journal etc.
- existed implementation has hard-coded logic for example in case of having several mime_types in query(all mime_types will be ORed despite what user wants).
Scope
- implementation in Datastore
- provide new dbus method to search
- support existed find() and mark it deprecated
How To Test
Run unit tests.
User Experience
If this feature is noticeable by its target audience, how will their experiences change as a result? Describe what they will see or notice.
Dependencies
Just regular glucose dependencies.
Contingency Plan
None necessary, revert to previous release behaviour.
Documentation
Release Notes
The Sugar Release Notes inform end-users about what is new in the release. An Example is 0.84/Notes. The release notes also help users know how to deal with platform changes such as ABIs/APIs, configuration or data file formats, or upgrade concerns. If there are any such changes involved in this feature, indicate them here. You can also link to upstream documentation if it satisfies this need. This information forms the basis of the release notes edited by the release team and shipped with the release.