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 <[email protected]> wrote: > Mariano, > > On 02 Oct 2013, at 20:49, Mariano Martinez Peck <[email protected]> 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
