628
edits
Changes
Jump to navigation
Jump to search
Line 1:
Line 1: − + + + Line 8:
Line 10: − + Line 18:
Line 20: − + − + − Instead of having dictionary ''query'' argument in ''org.laptop.sugar.DataStore::find()'' method, use plain string of [http://www.xapian.org/docs/queryparser.html full featured] query request i.e. use all system query parameters(like timestamp, mime_type etc.) in query string.+ − 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 ====+ − Sugar fills these terms on its own.+ + + + + Line 44:
Line 49: + + + + + + + + + + + + + + + + + + + + + + − + − | TODO: propose adding this field to DS − |- − | ''buddies_count'' − | sorted − | (?) + − + − − The purpose of having predefined users terms: − * Shell or activities can fill these terms implicitly e.g. by parsing metedata of downloaded files(audio, video etc.) − * in some UI(for example books viewer) having some of these terms in separate columns in list view could make sense − * we can provide sorting and ranging options only for known(by Datasotre) terms − * provide [http://dublincore.org/documents/dces/ Dublin Core] set of metadata fields Line 144:
Line 161: − + − | sorted − |- − | ''track_number'' − + − − ==== 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"'' Line 188:
Line 190: − + − * 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 use system terms in Journal search bar − * 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). − * provide new dbus method to search − * support existed find() and mark it deprecated − Run unit tests.+ + + + + + + + + + − + − * use tags with prefixes to differentiate them from regular words e.g. having substring ''books:favorite'' in tags field, user can type ''books:favorite'' in search bar and differentiate word ''favorite'' with prefix ''books'' from other ''books'' words. Line 219:
Line 224: − + Line 227:
Line 232: − − − [[Category:Feature Page Incomplete]] − [[Category:Feature]]
Features/Plain Query Format (view source)
Revision as of 17:01, 5 November 2013
, 17:01, 5 November 2013no edit summary
<noinclude>{{GoogleTrans-en}}{{TOCright}}</noinclude>
<noinclude>{{GoogleTrans-en}}{{TOCright}}
[[Category:Feature Page Incomplete]]
[[Category:FeatureObsoleted|Plain Query Format]]</noinclude>
<!-- All fields on this form are required to be accepted.
<!-- All fields on this form are required to be accepted.
== Summary ==
== Summary ==
Provide simple string query format for Datastore find() method to cover all kinds of requests.
Provide a simple string query format for the Datastore find() method to cover all kinds of requests.
== Owner ==
== Owner ==
* Targeted release: ?
* Targeted release: ?
* Last updated: Fri Jul 17 06:34:13 UTC 2009
* Last updated: Tue Aug 25 07:59:58 UTC 2009
* Percentage of completion: stopped, highly depends on [[Version support for datastore/Proposal]]
* Percentage of completion: 90%, core part was implemented within [[Version support for datastore/Proposal]]
== Detailed Description ==
== Detailed Description ==
Let users create complex queries with all possible terms (see Xapian [http://xapian.org/docs/glossary.html glossary]) including system ones. Users can use in query string [[#System prefixes|system]] prefixes and predefined set of [[#Users predefined prefixes|custom]] prefixes.
Prefixes in query string could look like
<prefix>:<one-word-value>
<prefix>:"<multi-word-value>"
Values for system prefixes, Sugar fills on its own, i.e., if ''title'' metadata field is ''My activity'', user can type ''title:"My activity"'' in query string to search ''My activity'' substring only within ''title'' fields.
Values for [[#Users predefined prefixes|custom]] prefixes user should place to ''tags'' metadata field in the same form like in query string.
If value is multi-worded, any of these words could be used in query, e.g., ''title:My'' or ''title:activity''.
==== System prefixes ====
{| border=1 cellpadding=3 style="border: 1px solid white; border-collapse: collapse; background: #e3e4e5;"
{| border=1 cellpadding=3 style="border: 1px solid white; border-collapse: collapse; background: #e3e4e5;"
|
|
| [http://dublincore.org/documents/dces/#identifier identifier]
| [http://dublincore.org/documents/dces/#identifier identifier]
|
|-
|-
| ''bundle_id''
| ''bundle_id''
|
|
| postponed until we decide to use Journal to represent activities
|-
|-
| ''mime_type''
| ''mime_type''
|
|
| [http://dublincore.org/documents/dces/#format format]
| [http://dublincore.org/documents/dces/#format format]
|
|-
|-
| ''title''
| ''title''
| sorted
| sorted
| [http://dublincore.org/documents/dces/#title title]
| [http://dublincore.org/documents/dces/#title title]
|
|-
| ''activity''
|
|
|
|-
|-
| ''activity_id''
| ''activity_id''
|
|
|
|-
|-
| ''timestamp''
| ''timestamp''
| ranged sorted
| ranged sorted
|
|
|-
|-
| ''keep''
| ''keep''
|
|
|
|-
|-
| ''tags''
| ''tags''
|
|
| see [[#Users predefined terms]]
|-
|-
| ''filesize''
| ''filesize''
| ranged sorted
| ranged sorted
|
|
| TODO: propose adding this field to DS
| postponed for [[Features/Unified Browser for Objects]]
|-
|-
| ''participant''
| ''participant''
| sorted
| sorted
|
|
|
|
|-
|-
| ''description''
| ''description''
|
|
| [http://dublincore.org/documents/dces/#description description]
| [http://dublincore.org/documents/dces/#description description]
|
|-
|-
|}
|}
==== Users predefined terms ====
==== Users predefined prefixes ====
{| border=1 cellpadding=3 style="border: 1px solid white; border-collapse: collapse; background: #e3e4e5;"
{| border=1 cellpadding=3 style="border: 1px solid white; border-collapse: collapse; background: #e3e4e5;"
| [http://dublincore.org/documents/dces/#type type]
| [http://dublincore.org/documents/dces/#type type]
|-
|-
| ''album''
| ''track''
| ranged sorted
| ranged sorted
|-
|-
| ''disc_number''
| ''disc''
| ranged sorted
| ranged sorted
|-
|-
|}
|}
==== Result set control parameters ====
==== Result set control parameters ====
== Benefit to Sugar ==
== Benefit to Sugar ==
* simple(plain string in comparing with existed API with dictionary find()'s argument) query format for dbus find() method
* Feature lets users specify exact metadata fields to search for.
== Scope ==
== Scope ==
* implementation in Datastore
* implementation in Datastore
== How To Test ==
== How To Test ==
''This does not need to be a full-fledged document. Describe the dimensions of tests that this feature is expected to pass when it is done. If it needs to be tested with different hardware or software configurations, indicate them. The more specific you can be, the better the community testing can be.''
''Remember that you are writing this how to for interested testers to use to check out your feature - documenting what you do for testing is OK, but it's much better to document what *I* can do to test your feature.''
''A good "how to test" should answer these four questions:''
* ''What special hardware / data / etc. is needed (if any)?
* ''How do I prepare my system to test this feature? What packages need to be installed, config files edited, etc.?
* ''What specific actions do I perform to check that the feature is working like it's supposed to?
* ''What are the expected results of those actions?''
== User Experience ==
== User Experience ==
* In Journal search bar users can use system terms e.g. ''timestamp:<date1>..<date2> AND mime_type="text/plain" AND participant:me'''
* feature just expands query dictionary
== Dependencies ==
== Dependencies ==
* [http://www.xapian.org/docs/queryparser.html Xapian query language]
* [http://www.xapian.org/docs/queryparser.html Xapian query language]
* [http://en.wikipedia.org/wiki/Dublin_Core Dublin Core metadata element set]
* [http://dublincore.org/documents/usageguide/ Using Dublin Core]
* [http://lcweb2.loc.gov/diglib/loc.terms/relators/dc-relators.html Relator Terms and Dublin Core Elements]
* [http://lcweb2.loc.gov/diglib/loc.terms/relators/dc-relators.html Relator Terms and Dublin Core Elements]
== Comments and Discussion ==
== Comments and Discussion ==
* See [[{{TALKPAGENAME}}|discussion tab for this feature]] <!-- This adds a link to the "discussion" tab associated with your page. This provides the ability to have ongoing comments or conversation without bogging down the main feature page -->
* See [[{{TALKPAGENAME}}|discussion tab for this feature]] <!-- This adds a link to the "discussion" tab associated with your page. This provides the ability to have ongoing comments or conversation without bogging down the main feature page -->