What is GemStone
When you ask a Smalltalker what Smalltalk is, you will find many different answers: a language, an environment, an object system, a platform or simply a combination of all of those or more. With GemStone, I have a similar feeling. I think different people will answer differently. To me, GemStone is an object system with two big concepts included: an object database and a language. Others will say that it’s a transactional or persistent Smalltalk, an object database, etc.
Before continuing, let me clarify a few things for this post and all the posts I will write after this one:
– I will not be discussing here relational databases vs object databases vs NoSQL. That’s a whole other discussion that I am not willing to write about right now.
– These posts are aimed mostly for Smalltalkers and GemStone newbies, but not for GemStone experts.
Ok…that being clarify…let’s start. When I refer to an object database, I mean exactly that: an Object Database Management System. Rather than dealing with tables as in relational databases, we can directly persist and query objects. Most of the OODB I have seen in other languages, are kind of an external piece of software that is only a database (just as relational databases are). For the moment, just imagine any of the relational databases you know but storing objects instead. In this case, you still need a language (and probably a VM running that language) for your application logic and you still must communicate to the database to perform the storage and retrieval of objects. I know… that should already be easier than dealing with relational databases but I personally think it could be better.
GemStone goes a step forward. What if the “database” would also include the language to run your application? Sounds cool, doesn’t it? So, this is the second concept GemStone has: it’s also a language implementation in itself. And which language? Smalltalk, of course!!! This means GemStone IS a Smalltalk dialect, just as any other dialect like Pharo, Visual Works, VisualAge, etc. So… GemStone is a Smalltalk dialect but also acts as an object database. You might be thinking “any Smalltalk can act as an object database because we have image persistency”. Fair enough. However, image persistency lacks lots of needed features to be a really scalable database (we will talk about this in other posts).
GemStone analogy to an image-based Smalltalk
As I said, the aim of these posts is to explain GemStone in a way that most readers can get it. And sometimes a good way to do so is by making a comparison to what we already know. So… let’s take an example with Pharo. Say we have one application running in one image. Soon, one image can start to be too little power and we need to scale. Smalltalk is cool and allow us to run the very same image with N number of VMs. Ok… so now we have 10 VMs running our app. Imagine this app needs persistency (as most apps do). If the database is outside Pharo (say a relational DB, NoSQL, etc), then we have no problem since the access to the database from multiple images will be correctly synchronized. But would you be allowed to use image persistency in this scenario? Of course not, because it’s not synchronized among all the VMs. But hell… that would be nice, wouldn’t it?
GemStone offers exactly what I would like: multiple (hundreds) Smalltalk VMs running and sharing the same “image” (repository/database of objects) in a synchronized fashion.
Note, however, that GemStone does NOT have a UI (it is headless) nor development tools (no IDE). So you still need another Smalltalk to develop your app code. And this is why the Pharo / GemStone combination is so great. But I will talk about this in another post.
To sum up
So you are the happiest programmer on the block. Your language has closures (have you ever try to imagine not using closures again???), an amazingly simple syntax, a small learning curve, decades of maturity, serious open-source and free dialects available, etc. Now I tell you can literally run hundreds of Smalltalk VMs all sharing the same repository of objects. But not only that… also imagine not having to write a simple mapping to SQL. Imagine that saving an object in the database is just adding an object to a collection (“clientList add: aClient”) and a query as a normal select (“clientList select: [:each | each age = 42 ]”). BTW… Did someone notice that, apart from selecting via an instance variable (‘age’ in this example), I can also send other domain specific messages? Say…. “clientList select: [:each | each associatedBankPollicy = BankPolicy strict ]”.
Ok, you might still not be convinced. What if I also tell you GemStone supports:
- Multiple-user database support
- Indexes and reduce conflict Collection classes
- Distributed env (imagine that your hundred VMs can also be running in different nodes!
- Fault tolerance
- Security at different levels (even at object level)
- 64 bits VMs and multi-cpu VMs
- Free license with generous limits
Ok…too much info for today. As you can note, I am very happy with these technologies so I will try to be objective… but I cannot promise you anything hahaha! I hope I have provoked and intrigued you enough to read on the future posts.