Talk:Version support for datastore/Proposal - Revision history

FGrose: update link for Google Doc

2010-12-06T05:22:07Z

update link for Google Doc

← Older revision		Revision as of 01:22, 6 December 2010
Line 26:		Line 26:

	;Eben & Tomeu:		;Eben & Tomeu:
	This thread, http://www.mail-archive.com/sugar-devel@lists.sugarlabs.org/msg06008.html, consolidated in context, https://docs.google.com/Doc?docid=0AUl2E5uTm959ZGd3N3FucXdfMWhzbjVjeGht&hl=en		This thread, http://www.mail-archive.com/sugar-devel@lists.sugarlabs.org/msg06008.html, consolidated in context,

			https://docs.google.com/Doc?docid=0AbFyRSVE0dmOZGQ5emZjOTZfMzBoeG1qMjhqbg&hl=en

			sugarlabs.org Google Docs original:

			https://docs.google.com/Doc?docid=0AUl2E5uTm959ZGd3N3FucXdfMWhzbjVjeGht&hl=en

	=== IRC notes ===		=== IRC notes ===

FGrose at 02:37, 31 July 2009

2009-07-31T02:37:46Z

← Older revision		Revision as of 22:37, 30 July 2009
Line 25:		Line 25:
	:This is also the reason that the latest Journal designs split the UI into "action" and "object" views. The action view would be a temporal history of everything you've done (with each version through time). The object view would represent each object only once, by it's most recent version, thus providing a much shorter list.		:This is also the reason that the latest Journal designs split the UI into "action" and "object" views. The action view would be a temporal history of everything you've done (with each version through time). The object view would represent each object only once, by it's most recent version, thus providing a much shorter list.

			;Eben & Tomeu:
	This thread, http://www.mail-archive.com/sugar-devel@lists.sugarlabs.org/msg06008.html, consolidated in context, https://docs.google.com/Doc?docid=0AUl2E5uTm959ZGd3N3FucXdfMWhzbjVjeGht&hl=en		This thread, http://www.mail-archive.com/sugar-devel@lists.sugarlabs.org/msg06008.html, consolidated in context, https://docs.google.com/Doc?docid=0AUl2E5uTm959ZGd3N3FucXdfMWhzbjVjeGht&hl=en

FGrose at 02:35, 31 July 2009

2009-07-31T02:35:17Z

← Older revision		Revision as of 22:35, 30 July 2009
Line 7:		Line 7:
	[[Image:journal-version-mockup-4.png\|800px\|thumb\|left\|Third mockup: combo box with Favourite stars (closed)]]		[[Image:journal-version-mockup-4.png\|800px\|thumb\|left\|Third mockup: combo box with Favourite stars (closed)]]
	[[Image:journal-version-mockup-5.png\|800px\|thumb\|left\|Third mockup: combo box with Favourite stars (open)]]		[[Image:journal-version-mockup-5.png\|800px\|thumb\|left\|Third mockup: combo box with Favourite stars (open)]]
			<br clear>
	== Scratch area ==		== Scratch area ==

Line 24:		Line 24:
	:Basically, all versions of a document would appear within the list view timeline. Their order within the list would be determined by their timestamp. If I work on 3 iterative versions of a document, then go back to the second version and make changes, I get a new 4th version which appears as the most recent item in the Journal. It doesn't matter (at least here) that I technically have a branch at version 2, which has children 3 and 4. What matters in the Journal perspective is that I worked on version 4 most recently. The tree is flattened into a list in the time dimension.		:Basically, all versions of a document would appear within the list view timeline. Their order within the list would be determined by their timestamp. If I work on 3 iterative versions of a document, then go back to the second version and make changes, I get a new 4th version which appears as the most recent item in the Journal. It doesn't matter (at least here) that I technically have a branch at version 2, which has children 3 and 4. What matters in the Journal perspective is that I worked on version 4 most recently. The tree is flattened into a list in the time dimension.
	:This is also the reason that the latest Journal designs split the UI into "action" and "object" views. The action view would be a temporal history of everything you've done (with each version through time). The object view would represent each object only once, by it's most recent version, thus providing a much shorter list.		:This is also the reason that the latest Journal designs split the UI into "action" and "object" views. The action view would be a temporal history of everything you've done (with each version through time). The object view would represent each object only once, by it's most recent version, thus providing a much shorter list.

			This thread, http://www.mail-archive.com/sugar-devel@lists.sugarlabs.org/msg06008.html, consolidated in context, https://docs.google.com/Doc?docid=0AUl2E5uTm959ZGd3N3FucXdfMWhzbjVjeGht&hl=en

	=== IRC notes ===		=== IRC notes ===

Alsroot: /* Datastore feature requests */

2009-05-22T04:42:07Z

Datastore feature requests

← Older revision		Revision as of 00:42, 22 May 2009
Line 73:		Line 73:
	= Datastore feature requests =		= Datastore feature requests =

	~~=== Features that could benefit Library activity ===~~		* [[Development_Team/Release/Roadmap/0.86#Datastore_features_that_could_benefit_Library]]

	~~These features can benefit~~ [[~~Activities~~/~~Library]] activity. At present(for 0.82~~/0.84) Library uses "rich" datastore client which fetches all Journal objects to make short list of objects(by collapsing all versions to one item), moreover it has to unzip .xo bundles to get ''bundle_id'' value. So its not good.

	With all these features implemented Library can use "thin" datastore client and not fetch all objects, just make proper request for datasotre.find() to get sorted and collapsed objects by portions (by using offset/limit find() arguments).

	~~====== Get collapsed find()'s resultset ======~~

	~~Let user call datastore.find() to get list of collapsed objects(all versions by one item).~~

	~~That should mean that any datastore object should have "object id":~~
	* ''activity_id'' for objects that were generated by activities (already implemented)
	* ''bundle_id'' for .xo bundles in the Journal
	* ''uid'' for other objecets (already implemented)

	~~====== History of collapsed object ======~~

	~~Let datastore clients browse history of collapsed objects:~~
	* for ''activity_id'' objects - sort by timestamp (already impelemented)
	* for ''bundle_id'' objects - sort by ''activity_version''(or so) field

	~~====== Sort find()'s resultset ======~~

	~~Let datastore clients sort objects by any field(not only predefined like uid, activity_id etc).~~

Alsroot: /* Provide object id field */

2009-05-18T07:24:19Z

Provide object id field

← Older revision		Revision as of 03:24, 18 May 2009
Line 79:		Line 79:
	With all these features implemented Library can use "thin" datastore client and not fetch all objects, just make proper request for datasotre.find() to get sorted and collapsed objects by portions (by using offset/limit find() arguments).		With all these features implemented Library can use "thin" datastore client and not fetch all objects, just make proper request for datasotre.find() to get sorted and collapsed objects by portions (by using offset/limit find() arguments).

	====== ~~Provide object id field~~ ======		====== Get collapsed find()'s resultset ======

			Let user call datastore.find() to get list of collapsed objects(all versions by one item).

	That should mean that any datastore object should have "object id":		That should mean that any datastore object should have "object id":

Alsroot: /* Datastore API feature requests */

2009-05-18T07:19:45Z

Datastore API feature requests

← Older revision		Revision as of 03:19, 18 May 2009
Line 71:		Line 71:
	* [http://wiki.laptop.org/go/Journal%2C_reloaded Journal reloaded]		* [http://wiki.laptop.org/go/Journal%2C_reloaded Journal reloaded]

	= Datastore ~~API~~ feature requests =		= Datastore feature requests =

	=== Features that could benefit Library activity ===		=== Features that could benefit Library activity ===

Alsroot: /* Datastore API feature requests */

2009-05-18T07:12:00Z

Datastore API feature requests

← Older revision		Revision as of 03:12, 18 May 2009
Line 71:		Line 71:
	* [http://wiki.laptop.org/go/Journal%2C_reloaded Journal reloaded]		* [http://wiki.laptop.org/go/Journal%2C_reloaded Journal reloaded]

	== Datastore API feature requests ==		= Datastore API feature requests =

	==== Features that could benefit Library activity ====		=== Features that could benefit Library activity ===

	These features can benefit [[Activities/Library]] activity. At present(for 0.82/0.84) Library uses "rich" datastore client which fetches all Journal objects to make short list of objects(by collapsing all versions to one item), moreover it has to unzip .xo bundles to get ''bundle_id'' value. So its not good.		These features can benefit [[Activities/Library]] activity. At present(for 0.82/0.84) Library uses "rich" datastore client which fetches all Journal objects to make short list of objects(by collapsing all versions to one item), moreover it has to unzip .xo bundles to get ''bundle_id'' value. So its not good.

Alsroot: /* Let all activities browse datastore in "objects" mode */

2009-05-18T07:10:15Z

Let all activities browse datastore in "objects" mode

← Older revision		Revision as of 03:10, 18 May 2009
Line 73:		Line 73:
	== Datastore API feature requests ==		== Datastore API feature requests ==

	==== ~~Let all activities browse datastore in "objects" mode~~ ====		==== Features that could benefit Library activity ====

	So ~~any activity~~ can datastore.find() to get collapsed objects(~~all versions~~ by ~~one resultset item~~).		These features can benefit [[Activities/Library]] activity. At present(for 0.82/0.84) Library uses "rich" datastore client which fetches all Journal objects to make short list of objects(by collapsing all versions to one item), moreover it has to unzip .xo bundles to get ''bundle_id'' value. So its not good.

			With all these features implemented Library can use "thin" datastore client and not fetch all objects, just make proper request for datasotre.find() to get sorted and collapsed objects by portions (by using offset/limit find() arguments).

			====== Provide object id field ======

	That should mean that any datastore object should have "object id":		That should mean that any datastore object should have "object id":
Line 81:		Line 85:
	* ''bundle_id'' for .xo bundles in the Journal		* ''bundle_id'' for .xo bundles in the Journal
	* ''uid'' for other objecets (already implemented)		* ''uid'' for other objecets (already implemented)

			====== History of collapsed object ======

	Let datastore clients browse history of collapsed objects:		Let datastore clients browse history of collapsed objects:
	* for ''activity_id'' objects - sort by timestamp (already impelemented)		* for ''activity_id'' objects - sort by timestamp (already impelemented)
	* for ''bundle_id'' objects - sort by ''activity_version''(or so) field		* for ''bundle_id'' objects - sort by ''activity_version''(or so) field

			====== Sort find()'s resultset ======

	Let datastore clients sort objects by any field(not only predefined like uid, activity_id etc).		Let datastore clients sort objects by any field(not only predefined like uid, activity_id etc).

	This features can benefit [[Activities/Library]] activity, at present(for 0.82/0.84) Library uses "rich" datastore client which fetches all Journal objects to make short list of objects(by collapsing all versions to one item), moreover it has to unzip .xo bundles to get ''bundle_id'' value.

	With all these features implemented Library can use "thin" datastore client and not fetch all objects, just make proper request for datasotre.find() to get sorted and collapsed objects by portions (by using offset/limit find() arguments).

Alsroot: /* Let all activities browse datastore in "objects" mode */

2009-05-18T06:33:48Z

Let all activities browse datastore in "objects" mode

← Older revision		Revision as of 02:33, 18 May 2009
Line 88:		Line 88:
	Let datastore clients sort objects by any field(not only predefined like uid, activity_id etc).		Let datastore clients sort objects by any field(not only predefined like uid, activity_id etc).

	This features can benefit [[Activities/Library]] activity, at present(for 0.82/0.84) Library uses "rich" datastore client which fetches all Journal objects to make short list of objects(by collapsing all versions to one item), moreover it has to unzip .xo bundles to get ''bundle_id'' value.~~<br>~~		This features can benefit [[Activities/Library]] activity, at present(for 0.82/0.84) Library uses "rich" datastore client which fetches all Journal objects to make short list of objects(by collapsing all versions to one item), moreover it has to unzip .xo bundles to get ''bundle_id'' value.

	With all these features implemented Library can use "thin" datastore client and not fetch all objects, just make proper request for datasotre.find() to get sorted and collapsed objects by portions (by using offset/limit find() arguments).		With all these features implemented Library can use "thin" datastore client and not fetch all objects, just make proper request for datasotre.find() to get sorted and collapsed objects by portions (by using offset/limit find() arguments).

Alsroot: /* Let all activities browse datastore in "objects" mode */

2009-05-18T06:33:21Z

Let all activities browse datastore in "objects" mode

← Older revision		Revision as of 02:33, 18 May 2009
Line 88:		Line 88:
	Let datastore clients sort objects by any field(not only predefined like uid, activity_id etc).		Let datastore clients sort objects by any field(not only predefined like uid, activity_id etc).

	This features can benefit [[Activities/Library]] activity, at present(for 0.82/0.84) Library uses "rich" datastore client which fetches all Journal objects to make short list of objects(by collapsing all versions to one item), moreover it has to unzip .xo bundles to get ''bundle_id'' value.		This features can benefit [[Activities/Library]] activity, at present(for 0.82/0.84) Library uses "rich" datastore client which fetches all Journal objects to make short list of objects(by collapsing all versions to one item), moreover it has to unzip .xo bundles to get ''bundle_id'' value.<br>
			With all these features implemented Library can use "thin" datastore client and not fetch all objects, just make proper request for datasotre.find() to get sorted and collapsed objects by portions (by using offset/limit find() arguments).