Updates This Week to the Sugar Almanac - Using the Datastore and More

[Faisal Anwar]

Hi Tomeu,

Thanks so much for the clarifications. I understand now the abstraction
intended for metadata accessed through DSMetadata and DSObject and will try
to write that up a little more forcefully. I guess the main thing I was
concerned about was having a consistent and lasting interface to the
datastore (which can certainly be implemented in the form of a dictionary if
that is most appropriate). I hope this abstraction will hold moving forward
so that activity developers are confident that their hooks in to datastore
will work with the same behavior over time (this is part of the purpose of
the documentation I'm working on).

With regards to the lower level DBus calls in datastore and elsewhere, what
I'm really looking out for is what levels of the tech stack an activity
developer will need to learn to build a fairly robust and complex activity.
Of course, for some things lower level Dbus calls may be unavoidable, but
I'm assuming that there should be a substantive interface in python that
abstracts away the Dbus functionality for most developers. As I go through
more of the code in datastore, presence, and elsewhere, I'll try to identify
cases where perhaps a low-level Dbus call could be abstracted to some
standard python calls.


Faisal


On Wed, Jun 25, 2008 at 4:28 AM, Tomeu Vizoso <tomeu at tomeuvizoso.net> wrote:

> Hi Faisal, some answers below:
>
> 2008/6/24 Faisal Anwar <fanwar at mediamods.com>:
> >
> > ?? Is there a specific reason why there isn't a "set()" method in the
> > datastore.DSMetadata class? Shouldn't people be given standard accessors
> and
> > mutators to work with this code. This is especially confusing because it
> > seems there is presently a "get()" method, but the set() method does not
> > exist (so the abstraction is completely different based on whether you
> are
> > getting or setting data). d
>
> That class is to be used in the same way as dictionaries in python, so
> the API mimics that. By implementing __getitem__, __setitem__ and
> get(), the user can do the following:
>
> obj.metadata['my-property'] = 'blah blah'
> print obj.metadata['my-property']
> print obj.metadata.get('my-property', 'N/A')
>
> > ?? Several things that are currently documented at
> > http://wiki.laptop.org/go/Low-level_Activity_API#Keeping_and_Resumingare
> > outdated. Specifically, it says datastore.create() returns the object_id.
> > That's wrong, it returns the actual DSObject. Furthermore, it says there
> are
> > methods called datastore.update and datastore.get_properties, but they
> don't
> > exists.
>
> That page documents the low level API that can be used by all
> activities, no matter in which language are written. sugar.datastore
> is a higher level API only available to python activities. See here
> for the D-Bus API of the datastore:
>
>
> http://dev.laptop.org/git?p=projects/datastore;a=blob;f=src/olpc/datastore/datastore.py
>
> > ?? The deletion/destruction of datastore activities seems to be a little
> > confusing. In particular, there is a datastore.delete() method and there
> is
> > also a DSObject.destroy() method. Why doesn't datastore.delete() simply
> call
> > the destroy() method in its code so that any files associated with the
> > deleted datastore object are also removed. Given that a warning is thrown
> > telling the developer that an object is deleted without directly calling
> > DSObject.destroy() (it is called indirectly through the __del__ method,
> but
> > why not have things more explicit?), I'm not sure why this isn't just
> done
> > programmatically. Is there ever a reason why one woul perform a delete()
> on
> > an object without doing the functionality in DSObject.destroy() and are
> any
> > of these reasons compelling enough that we should keep the delete() and
> > destroy() methods as they are now?
>
> Well, datastore.delete() instructs the datastore to delete the object
> from its persistent storage. DSObject.destroy() is intended to be
> called when the user stops needing the transient instance that
> represents the persistent object.
>
> This is similar to DB programming with SQL in procedural languages,
> deleting the resultset object is not the same as deleting the rows
> that are contained in that resultset.
>
> > Other questions may come up as people work more on this documentation. In
> > the meantime, I'd greatly appreciate any feedback on the existing work
> and
> > also any answers to the questions above.
>
> Nice work, more questions welcome.
>
> Regards,
>
> Tomeu
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.laptop.org/pipermail/devel/attachments/20080627/6c04163a/attachment.html>