u1db-discuss team mailing list archive

[John Meinel <john@xxxxxxxxxxxxxxxxx>]

I think his biggest point is that we have a few functions that return a
tuple/multiple return values, and that doesn't map well to other languages.
Which I agree with.

John
=:->
On Nov 11, 2011 9:52 AM, "Stuart Langridge" <stuart.langridge@xxxxxxxxxxxxx>
wrote:

> On Thu, 2011-11-10 at 22:13 -0500, Rodney Dawes wrote:
>
> >   Document   create_doc (string content, string doc_id=None)
> >   Document   get_doc    (string doc_id, bool check_for_conflicts=True)
> >   Document[] get_docs   (string doc_id[], bool check_for_conflicts=True)
> >   long       put_doc    (Document)
> >   void       delete_doc (Document)
> >
> > Here, Document would be a simple object containing attributes for the
> > id, revision, and content. The mentioned calls would still be on the
> > Database object. The constructor arguments for Document, would be the
> > id, revision, and content.
> >
> > This sort of API design would make it easier to keep consistency across
> > the board for all related methods, and would translate much better to
> > other languages, such as C, Vala, Java, etc… which are not dynamic, and
> > must have complex types defined to hold this data.
>
> I think you might be under a bit of a misapprehension here. The thing
> that you pass to the Python functions as a "doc" is a JSON string. It's
> not a Python dictionary or some other complex type. Our basic "document"
> is a string containing a JSON serialisation of the document; it's not an
> object.
>
> sil
>
>
>
> --
> Mailing list: https://launchpad.net/~u1db-discuss
> Post to     : u1db-discuss@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~u1db-discuss
> More help   : https://help.launchpad.net/ListHelp
>