Difference between revisions of "Features/Plain Query Format"

 
(66 intermediate revisions by 2 users not shown)
Line 1: Line 1:
<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.
Line 8: Line 10:
 
== 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 ==
  
* Name: [[User:alsroot| Aleksey Lim]]
+
* Name: ?
* Email: [[Special:Emailuser/alsroot|send an email]]
+
* Email: ?
  
 
== Current status ==
 
== Current status ==
  
* Targeted release: 0.86
+
* 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: 0%
+
* Percentage of completion: 90%, core part was implemented within [[Version support for datastore/Proposal]]
  
 
== Detailed Description ==
 
== Detailed Description ==
  
Instead of having complicated query format for org.laptop.sugar.DataStore::find(), use plane string [http://www.xapian.org/docs/queryparser.html full featured] query format i.e. use all system query parameters(like timestamp, mime_type etc.) with user query string(from former find()'s 'query' argument).
+
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.
  
All system, users predefined and some(its up to user) of users query terms will use prefixes like mime_type:"text/plain" or ctime:<date1>..<date2>
+
Prefixes in query string could look like
 +
<prefix>:<one-word-value>
 +
<prefix>:"<multi-word-value>"
  
==== System terms ====
+
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;"
Line 33: Line 43:
 
! Datastore field
 
! Datastore field
 
! Flags/Parameters
 
! Flags/Parameters
 +
! Dublin Core
 
! Notes
 
! Notes
 
|-
 
|-
| ''tree_id''
+
| ''uid''
|-
+
|
| ''version_id''
+
| [http://dublincore.org/documents/dces/#identifier identifier]
|-
+
|
| ''parent_id''
 
|-
 
| ''ctime''
 
| ranged sorted
 
 
|-
 
|-
 
| ''bundle_id''
 
| ''bundle_id''
|-
+
|
| ''entry_type''
+
|
|-
+
| postponed until we decide to use Journal to represent activities
| ''creator''
 
 
|-
 
|-
 
| ''mime_type''
 
| ''mime_type''
 +
|
 +
| [http://dublincore.org/documents/dces/#format format]
 +
|
 
|-
 
|-
 
| ''title''
 
| ''title''
 
| sorted
 
| sorted
 +
| [http://dublincore.org/documents/dces/#title title]
 +
|
 +
|-
 +
| ''activity''
 +
|
 +
|
 +
|
 
|-
 
|-
 
| ''activity_id''
 
| ''activity_id''
 +
|
 +
|
 +
|
 
|-
 
|-
 
| ''timestamp''
 
| ''timestamp''
 
| ranged sorted
 
| ranged sorted
 +
|
 +
|
 
|-
 
|-
 
| ''keep''
 
| ''keep''
 +
|
 +
|
 +
|
 +
|-
 +
| ''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
| TODO: propose adding this field to DS
+
|
 +
|
 +
|-
 +
| ''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;"
Line 78: Line 114:
 
! Datastore field
 
! Datastore field
 
! Flags/Parameters
 
! Flags/Parameters
 +
! Dublin Core
 
! Notes
 
! Notes
 
|-
 
|-
| ''artist''
+
| ''contributor''
 +
| sorted
 +
| [http://dublincore.org/documents/dces/#contributor contributor]
 
|-
 
|-
| ''album''
+
| ''coverage''
 +
| sorted
 +
| [http://dublincore.org/documents/dces/#coverage coverage]
 
|-
 
|-
| ''author''
+
| ''creator''
|
+
| sorted
| and composer as well
+
| [http://dublincore.org/documents/dces/#creator creator]
 
|-
 
|-
 
| ''date''
 
| ''date''
| ranged
+
| ranged sorted
 +
| [http://dublincore.org/documents/dces/#date date]
 +
|-
 +
| ''language''
 +
| sorted
 +
| [http://dublincore.org/documents/dces/#language language]
 +
|-
 +
| ''publisher''
 +
| sorted
 +
| [http://dublincore.org/documents/dces/#publisher publisher]
 +
|-
 +
| ''relation''
 +
| sorted
 +
| [http://dublincore.org/documents/dces/#relation relation]
 +
|-
 +
| ''rights''
 +
| sorted
 +
| [http://dublincore.org/documents/dces/#rights rights]
 +
|-
 +
| ''source''
 +
| sorted
 +
| [http://dublincore.org/documents/dces/#source source]
 
|-
 
|-
| ''genre''
+
| ''subject''
 +
| sorted
 +
| [http://dublincore.org/documents/dces/#subject subject]
 
|-
 
|-
| ''track_number''
+
| ''type''
| ranged
+
| sorted
 +
| [http://dublincore.org/documents/dces/#type type]
 
|-
 
|-
| ''track_count''
+
| ''track''
| ranged
+
| ranged sorted
 +
|-
 +
| ''disc''
 +
| ranged sorted
 +
|-
 +
|}
 +
 
 +
==== Result set control parameters ====
 +
 
 +
New find() method still has optional dictionary argument to control final result set.
 +
 
 +
{| border=1 cellpadding=3 style="border: 1px solid white; border-collapse: collapse; background: #e3e4e5;"
 +
|-style="background:#787878; color: white;"
 +
! Dictionary key
 +
! Notes
 
|-
 
|-
| ''disc_number''
+
| ''offset''
| ranged
 
 
|-
 
|-
| ''disc_count''
+
| ''limit''
| ranged
 
 
|-
 
|-
| ''copyright''
+
| ''order_by''
 
|-
 
|-
 +
| ''lang''
 +
| to setup stemming
 
|}
 
|}
  
 
== Benefit to Sugar ==
 
== Benefit to Sugar ==
  
* simple(plane 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.
* simple and new-feature-proof way to implement find method for example in CLI tools(because this tool needs only to pass plane 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 ==
 
== Scope ==
  
Datastore implementation and new API.
+
* implementation in Datastore
  
 
== How To Test ==
 
== How To Test ==
Line 134: Line 210:
  
 
== User Experience ==
 
== 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.''
+
 
 +
* feature just expands query dictionary
  
 
== Dependencies ==
 
== Dependencies ==
''What other packages (RPMs) depend on this package?  Are there changes outside the developers' control on which completion of this feature depends?  In other words, completion of another feature owned by someone else and might cause you to not be able to finish on time or that you would need to coordinate?  Other upstream projects like python?''
+
 
 +
Just regular glucose dependencies.
  
 
== Contingency Plan ==
 
== Contingency Plan ==
Line 146: Line 224:
  
 
* [http://www.xapian.org/docs/queryparser.html Xapian query language]
 
* [http://www.xapian.org/docs/queryparser.html Xapian query language]
 +
* [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]
  
 
== Release Notes ==
 
== Release Notes ==
Line 152: Line 232:
 
== 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 -->
 
 
[[Category:Feature Page Incomplete]]
 
[[Category:Feature]]
 

Latest revision as of 17:01, 5 November 2013


Summary

Provide a simple string query format for the Datastore find() method to cover all kinds of requests.

Owner

  • Name: ?
  • Email: ?

Current status

Detailed Description

Let users create complex queries with all possible terms (see Xapian glossary) including system ones. Users can use in query string system prefixes and predefined set of 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 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

Datastore field Flags/Parameters Dublin Core Notes
uid identifier
bundle_id postponed until we decide to use Journal to represent activities
mime_type format
title sorted title
activity
activity_id
timestamp ranged sorted
keep
tags see #Users predefined terms
filesize ranged sorted postponed for Features/Unified Browser for Objects
participant sorted
description description

Users predefined prefixes

Datastore field Flags/Parameters Dublin Core Notes
contributor sorted contributor
coverage sorted coverage
creator sorted creator
date ranged sorted date
language sorted language
publisher sorted publisher
relation sorted relation
rights sorted rights
source sorted source
subject sorted subject
type sorted type
track ranged sorted
disc ranged sorted

Result set control parameters

New find() method still has optional dictionary argument to control final result set.

Dictionary key Notes
offset
limit
order_by
lang to setup stemming

Benefit to Sugar

  • Feature lets users specify exact metadata fields to search for.

Scope

  • implementation in Datastore

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

  • feature just expands query dictionary

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.

Comments and Discussion