[Pharo-dev] Glorp, Fuel, Native postgres driver, Voyage/Mongo, any in GemStone?

Stéphane Ducasse stephane.ducasse at inria.fr
Wed Oct 2 16:13:05 EDT 2013


Mariano 

why 1Gb and not tomorrow afternoon 5 Gb and in two days 10 Gb?
Of course Pharo is limited and I hope that with the new Cog it will be different but soon it will not fit in the ram of your OS. 

Stef



> On Wed, Oct 2, 2013 at 4:42 PM, Sven Van Caekenberghe <sven at stfx.eu> wrote:
> Mariano,
> 
> On 02 Oct 2013, at 20:49, Mariano Martinez Peck <marianopeck at gmail.com> wrote:
> 
> > Hi guys.
> > First, let me apologize for the amount of emails I am sending. I am doing an analysis to see if GemStone is a good candidate for a project I am working and so it deserves some research.
> >
> > I wondered if any has ever tried porting any of these tools to GemStone: Fuel, Glorp, Native PostgreSQL driver, Voyage and MongoDB.
> 
> I do not understand.
> 
> IMHO there is only one reason to go to Gemstone, and that is to use its capabilities as OODB. All the technologies you mention are persistency related and would not be needed in that case, right ?
> 
> More or less. Fuel would be awesome to move data between Pharo and GemStone. SIXX has demonstrated some limitations. 
> And regarding Glorp / native postgres driver  and Voyage/Mongo is because what I may store in GemStone is not the only DB in the game. I may have OTHER DBs that for a reason not important here, should remain either in a relation DB or in Voyage. Yet, I need to query them somehow from Pharo. Of course, I can have a Pharo image that does the job and provides web-services (or anything similar) to my GemStone....but of course it is easier if these DB clients would work in GemStone as well....
>  
> 
> As you most probably know, you can get pretty far with Pharo.
> 
> Yes I know. But this particular application may have a lot of data processing, algorithms, etc, which may probably NOT fit in 1GB of memory and the effort to distribute the process among multiple images could be high.  
>  
> After that, there is load-balancing, partitioning, message queues. Pretty much what any technology stack does.
> 
> 
> Indeed. But I would still need a persistency solution that satisfy all my needs. I should write this down and compare the alternatives in Pharo. 
>  
> You will always find more tools and libraries on the Pharo side, as the community is much larger.
> 
> 
> Sure. But at least I would only miss the "deployment" libraries, since in any case I will continue developing in Pharo, so all the development tools and all the environment will be the same. 
> 
>  
> Thanks for the discussion!
> 
> 
> 
> -- 
> Mariano
> http://marianopeck.wordpress.com

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


More information about the Pharo-dev mailing list