[Pharo-dev] MongoGB GridFS driver for Pharo

Norbert Hartl norbert at hartl.name
Fri Apr 11 04:58:54 EDT 2014


Am 11.04.2014 um 09:08 schrieb roberto.minelli at usi.ch:

> 
> On Apr 10, 2014, at 1:18 PM, Norbert Hartl <norbert at hartl.name> wrote:
> 
>> 
>> Am 10.04.2014 um 11:17 schrieb Esteban Lorenzano <estebanlm at gmail.com>:
>> 
>>> Hi,
>>> 
>>> Voyage did not implement GridFS out of the box. 
>>> But It can be extended to use it, it does not looks as a real complicated API.
>>> 
>> Agreed. But I ask myself what is the use of GridFS in voyage. I would guess that in most use cases the access to GridFS needs to be offloaded of the image.
> 
> What about storing and retrieving documents that exceed the Mongo document size limit? :)
> 
Depends on your use case:

If you have a JSON document that exceeds 16MB then you should think about splitting it up and store the child elements as documents in the collection. At the same time you will be able to search in those documents which is IMHO not possible with GridFS at the moment

If you have something different and those documents are standalone then you are better off mapping a URI namespace directly via your frontend webserver. [1] [2].

If you need references from a „normal“ document to a GridFS document then there might be a chance storing it via the image makes sense (2nd case). 

In those scenarios you have two things that need to be stored separately. The normal documents and GridFS documents cannot be stored in the same collection. 

case 1: If you decide to make two requests from the client the mapping in the frontend server might come in handy. You would store the GridFS document first getting back a reference (id or URI) to it. That you can store in the normal document and store that document next. On retrieval of the GridFS document it is most likely you query the reference in the normal document. That request would then redirect to the GridFS mapped URI which would be served completely by the frontend server.

case 2: You want to make only one request for uploading both in a multipart message. This way it will be really difficult to treat both resources separately by the frontend server. In this case there is barely a chance other then the image receives the multipart message and stores both documents. But that won’t be fast and should only be done if the number uploads of those big things is rather small compared to the retrieval of the same. On retrieval time you should do the same as above: map the GridFS via frontend server and redirect from the image to retrieve the GridFS document.

So having GridFS support in the image can be useful while developing and for deploying case 2. So I’ll take it back partially :) But remember that accessing GridFS documents in the image is just copying a lot of bytes from one socket to another. Exactly the kind of things it is not good at.

Norbert

[1] https://bitbucket.org/onyxmaster/mod_gridfs
[2] https://github.com/mdirolf/nginx-gridfs


> Cheers,
> R
> 
>> 
>> Norbert
>> 
>>> Esteban
>>> 
>>> On 10 Apr 2014, at 11:07, roberto.minelli at usi.ch wrote:
>>> 
>>>> Hi guys,
>>>> 
>>>> I need to store objects (i.e., mongo documents) which exceeds the BSON-document size of 16MB.
>>>> 
>>>> I run into the “official” mongoDB solution, which is to use GridFS.
>>>> 
>>>> Does anyone know if there is any possibility to use GridFS within Pharo? For example with Voyage… or any other suggestion is highly appreciated!
>>>> 
>>>> Cheers,
>>>> Roberto
>>> 
>>> 
>> 
>> 
> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.pharo.org/pipermail/pharo-dev_lists.pharo.org/attachments/20140411/abe88fad/attachment-0002.html>


More information about the Pharo-dev mailing list