[Cubicweb] Which way to go to do remote RQL ?

Yann Cointepas yann at cointepas.net
Thu Aug 7 10:14:47 CEST 2014


Thanks for the awnser Aurélien.

Big requests are an issue in genetics. I am not directly involved here but
a collegue of mine (Antoine for those who know him) have reach the limit
and he had to develop a workaround for some requests (via a view allowing
to download the request in a JSON file).

I use multiple requests transactions because users are sending packages of
data. We garantie that a package that cannot be fully integrated in the
base will be rejected (and possibly corrected and resent by the user).
Rejected package leave nothing in the base. Since a package can contains
various data (e.g. MRI Scans, MRI scans with processing results, only
processing results, etc.), the content of the package in processed in a
transaction. At the top level of the code there is a try...except:
rollback() else: commit() and the DB insertion job is implemented in
various classes. Each class is responsible of a specific kind of data or
processing. Without commit/rollback, I would need to provide a way for
these classes to record all what they have done to allow to "undo"
everything that have been done prior to the error. AFAIK it is not trivial
to implement (and it already exists in Cubicweb).

Yann Cointepas            Tel: +33 1 69 08 78 31
CEA - Neurospin           Fax: +33 1 69 08 79 80
Bâtiment 145, Point Courrier 156
91191 Gif-sur-Yvette cedex, France


On Wed, Aug 6, 2014 at 6:42 PM, aurélien campéas <aurelien.campeas at gmail.com
> wrote:

> Hi,
>
>
> 2014-08-06 18:22 GMT+02:00 Yann Cointepas <yann at cointepas.net>:
>
> Hi,
>>
>> I need to know if there is a recommended way to remotely access a
>> Cubicweb instance via RQL from a Python script. AFAIK, there are several
>> options that are more or less obsolete (e.g. Pyro, ZMQ). What is going to
>> be supported in the future years ? Are the supported options compatible
>> with the following features :
>>
>> 1) Secure when used over internet.
>>
>
> https
>
>
>>
>> 2) Possibility to use commit/rollback
>>
>
>
> Each request is mapped to a transaction.
> For transactions spanning multiple requests, out of the box,
> you can use the "undo" api (if, hum, it is correctly exposed).
> There's no reason we can't provide more but please tell us
> your story.
>
>
>> 3) Possibility to use users login/password
>>
>
> or signed requests, as you wish.
>
>
>>
>> 4) Possibility to handle big query data, big request or big resultset
>>
>
> I contend that today CubicWeb can handle *fairly big* data,
> requests and result sets. But how big is big ?
>
>
>
>>
>> 5) Possibility to modify the database
>>
>
> Use the rqlcontroller cube.
>
>
>>
>> 6) Possibility to get an error message for bad queries
>>
>
> Check.
>
>
> Regards,
> Aurélien.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cubicweb.org/pipermail/cubicweb/attachments/20140807/25b3a7ba/attachment-0186.html>


More information about the Cubicweb mailing list