Features/Plain Query Format

Summary

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

Owner

• Name: ?
• Email: ?

Current status

• Targeted release: 0.86
• Last updated: Tue Aug 25 07:59:58 UTC 2009
• Percentage of completion: core part was implemented within Version support for datastore/Proposal, the final set of terms depends on Features/Tags in Journal

Detailed Description

Instead of having dictionary query argument in org.laptop.sugar.DataStore::find() method, use plain string of 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.

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
filesize	ranged sorted		TODO: propose adding this field to DS
participant	sorted		TODO: propose adding this field to DS
buddies_count	sorted		(?)
description		description

Users predefined terms

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 Dublin Core set of metadata fields

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

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"

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

• 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 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).

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

• In Journal search bar users can use system terms e.g. timestamp:<date1>..<date2> AND mime_type="text/plain" AND participant:me'
• 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.

Dependencies

Just regular glucose dependencies.

Contingency Plan

None necessary, revert to previous release behaviour.

Documentation

• Xapian query language
• Using Dublin Core
• Relator Terms and Dublin Core Elements

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

• See discussion tab for this feature