On Fri, Aug 5, 2011 at 11:57 AM, Mariano Martinez Peck <marianopeck@gmail.com> wrote:
I am looking at using Riak ( http://wiki.basho.com/ ) with Pharo. When storing a “business object” you have two choices:
- Store a binary BLOB representing your object graph. - Store the object graph as JSON data.
The last option essentially means you must do something similar to OR mapping, so I would prefer the first option. With Riak, you will soon be able to store additional indexed properties, which you later will be able to query. So you store your whole business object as a BLOB, together with those properties you need to query.
Hi guys. Sorry to come back with this old post, but now I am interested ;)
Right now, I have a requirement where I need to write a graph into a file. I am using Fuel for that. Each graph, has its own file. In the image side I just store the filename, When I need to load it it reads such file and materialize it with Fuel. I was thinking going a step forward and use a key/value (a.k.a no-sql) database.
With Fuel, I can take a graph, and serialize directly into a ByteArray, hence I can take a graph to swap, I assign an ID, and and save it into the database. In the image side, I keep that ID. Then, when needed, I search it in the database and then after with that ByteArray found, I materialize it with Fuel.
So...first question is, do you think that could be faster/better than directly writing into a file as I am doing now?
Now, which are the available Pharo wrappers for no-sql databases that let me do that? I would appreciate any link or documentation about them. What do I need to use such databases from Pharo? FFI and a library installed in my machine? are there binaries for Mac OS?
I am not a big expert, but here is what I know. Firstly most NoSQL databases expose their interface through network, for instance CouchDB uses standard HTTP. So in order to spek to CouchDB you just need http client library, and optionally some helper around it, there are a few such packages on sqeaksource. I would not expect typical NoSQL database outperform your approach on single machine setup, since they have many overheads you do not have like network, json parsing, etc. Situation in which they would make sense is where you need to access your objects from more than one machine, need indexing on various fields in the stored objects, load balanced servers and mirroring. Davorin Rusevljan http://www.cloud208.com/