On Tue, Dec 18, 2012 at 5:35 AM, Göran Krampe <goran@krampe.se> wrote:
Hey!
On 12/17/2012 07:08 PM, Torsten Bergmann wrote:
Persisting data is crucial for any application and there are many ways to do it. Be it RDBMS, NoSQL stuff or in-image persistency. There are many pre-built solutions: Gemstone, OpenDBX, SandstoneDB, Mongo, ...
From time to time I ask the question here on the list
to see how it evolves and what people actually use in their Pharo applications:
1. What persistence option do we currently have 2. What persistence is used in your Pharo application today 3. Which persistence solution you want to use/would you like to see in Pharo's future 4. What would you recommend.
I can give some light on a few options that I have been involved in:
TokyoTyrant =========== The "binding" I wrote hasn't been touched since I wrote it, but it is binary over SocketStream and VERY fast. There is now a new similar database called KyotoTycoon from the same author that he recommends as superior. Some differences:
http://stackoverflow.com/**questions/4178414/what-is-the-** difference-between-tokyo-**cabinet-and-kyoto-cabinet<http://stackoverflow.com/questions/4178414/what-is-the-difference-between-to...>
I am not using nor maintaining this library anymore though. Still the raw speed is amazing and if that is what you want then this one is hard to beat.
NOTE: Not sure how it operates under Pharo but since it runs on top of SocketStream I suspect it just works. If someone tries it out, let me know.
Phriak ====== This is a binding to Riak, perhaps the most insanely cool NoSQL database IMHO. Yeah, MongoDB is also very nice, but some aspects of Riak really makes me comfy and warm inside.
The binding was started by Runar Jordahl called "EpigentRiakInterface", then I did a friendly fork and improved it even more, and then Nicolas Petton joined and improved it LOTS more, and now lately Paul De Bruicker has also joined with commits.
Phriak is intentionally focused on Pharo and uses the Zinc components to implement the API which is HTTP based. Riak has protocol buffers too, but we haven't looked at that.
This binding is maintained, pretty complete and very easy to use. Riak is also extremely easy to install.
Oak === This is a not so well known little side project from Nicolas Petton that I also am messing around with now. Oak is an "OODBish layer" that first was written abstractly to work on top of Riak, MongoDB etc. Now we are refocusing it on Riak only, possibly keeping optional Memcache support.
Oak uses two other very nice new technologies in Pharo: Fuel and Ghost. Fuel is well known, very good serialization library basically. Ghost is a new small library for making well behaving proxies, using a smarter approach than the old "subclass ProtoObject and implement #doesNotUnderstand:".
:) Hope to have a journal paper soon!
Net result is a semi transparent OODB which stores objects as Fuel blobs in Riak with UUIDs as keys. The auto faulting is done using Ghost proxies (so parts of your domain model are loaded "on demand" when you send messages to them). Oak is not super automagic like Magma - it doesn't do GC for example. But it is quite fast, small codebase and since it has a very simple model you can use other aspects of Riak through Phriak on the side.
Oak is live and kicking and we are improving it by the day. So consider it a very interesting alpha, but still, small and simple codebase so you can use it already if you are not afraid to get your hands dirty.
Yes, Oak is cool. We should continue with it! Cheers, -- Mariano http://marianopeck.wordpress.com