Frankly, this project looks like joke... Victor Stan Schedule me: http://quicklyschedule.quicklyschedule.me/victor Add me to your address book - it's easy! http://contactmonkey.com/victor On Sun, Mar 31, 2013 at 9:40 PM, Paul DeBruicker <pdebruic@gmail.com> wrote:

http://www.garret.ru/goods.html

And there is a Smalltalk interface on squeaksource.

On 03/31/2013 04:43 PM, Victor Stan wrote:

...

Hi,

Are there any open source OODB's out there? Alternatives to GemStone?

I've briefly tried searching online, but I haven't found anything yet...

Cheers,

Victor Stan

Schedule me: http://quicklyschedule.quicklyschedule.me/victor

Add me to your address book - it's easy! http://contactmonkey.com/victor

On 04/01/2013 05:26 AM, Victor Stan wrote:

Magma seems to have some potential...

Also see Oak: http://goran.krampe.se/2012/12/29/oak/ ...which is an OODBish layer on top of Riak. Although I am itching to put HyperDex as backend - but my binding to HyperDex is not ready yet. regards, Göran PS. I love OODBs too but think the new NoSQL dbs in combination with some added "sugar" is a potent option.

On Fri, Apr 5, 2013 at 3:58 AM, Victor Stan <victor.stan@gmail.com> wrote:

Thanks, I can imagine GemStone is quite advanced. I am curious though about open source alternatives that do a good enough job for smaller projects.

Thanks for all the suggestions!

for simple use cases there is also Sandstone: http://onsmalltalk.com/sandstonedb-simple-activerecord-style-persistence-in-... Davorin Rusevljan http://www.cloud208.com/

+1 BTW, I think that's a shame for smalltalkers to have so many libs for external persistence solutions. That's not a paradox. Alternatives are good, but Smalltalk was the first environment that had built-in persistence as much as 35, if not 40 years ago. Is there much progress since that time? I wouldn't say so. GemStone is great, but it's monolithic. And pricey. And that's one more Smalltalk in our Balkans. Why Pharo or Squeak don't have a framework (based on Fuel for example) that allows to control changes, execute transaction, save some parts of image instead of whole image etc.? This could be less efficient then GemStone, but loadable on demand, customizable and usable in smaller projects. Maybe there's such a project living already? Or is it too much for modern Smalltalk? It's not complaining. I know the answer: there's no usable persistence solution because I didn't create it :) I just want to know if someone else thinks the same way as I do? Consider that a very first step towards starting such a project, if it is feasible at all… -- Best regards, Dennis Schetinin 2013/4/6 stephane ducasse <stephane.ducasse@free.fr>

Hi 2013/4/1 Victor Stan <victor.stan@gmail.com>

...

Hi,

Are there any open source OODB's out there? Alternatives to GemStone?

I think there is no alternavise to GemStone.

I hope not :) Gemstone is good but an ecosystem with only one solution would look rather limited to me.

Because GemStome is not just data store. It is applicaton server where you work in multi user image system. Imagine single Pharo image which can work under different parallel VM instances (maybe running on different machines) which have concurrent access to same image objects, can commit it changes (save same image).

Hi Esteban, Sure, I'm aware of those and other solutions and I've even used few of them. I'm sorry I can't explain myself adequately now, but I'm dreaming about some other kind of persistence, the one that (just like GemStone) doesn't make me to rebuild my application to migrate from image-based to a more granular solution. Or better, use the one from the very beginning if I want. Smalltalk monitors changes in source code (though it still does it in a bit coarse way… I mean storing final results instead of deltas etc.). We have great metaprogramming and reflection capabilities. We can hook quite deep into message passing. And we can patch our VM as a last resort. Why don't we still have some of the persistence features GemStone has, and have them as a loadable framework? Even for the price of lower performance? Perhaps, I'm a dreamer (sure I am) and don't understand some basic obstacles for that, but can someone explain what are they? -- Best regards, Dennis Schetinin 2013/4/8 Esteban Lorenzano <estebanlm@gmail.com>

Hi,

for smaller projects you have:

- the image it self :) - SandstoneDB http://www.squeaksource.com/SDGoodsStore.html - Magma http://www.squeaksource.com/Magma.html - ... and I'm sure there are others :)

Esteban

On Apr 6, 2013, at 4:40 PM, Dennis Schetinin <chaetal@gmail.com> wrote:

+1

BTW, I think that's a shame for smalltalkers to have so many libs for external persistence solutions. That's not a paradox. Alternatives are good, but Smalltalk was the first environment that had built-in persistence as much as 35, if not 40 years ago. Is there much progress since that time? I wouldn't say so. GemStone is great, but it's monolithic. And pricey. And that's one more Smalltalk in our Balkans.

Why Pharo or Squeak don't have a framework (based on Fuel for example) that allows to control changes, execute transaction, save some parts of image instead of whole image etc.? This could be less efficient then GemStone, but loadable on demand, customizable and usable in smaller projects. Maybe there's such a project living already? Or is it too much for modern Smalltalk?

It's not complaining. I know the answer: there's no usable persistence solution because I didn't create it :) I just want to know if someone else thinks the same way as I do? Consider that a very first step towards starting such a project, if it is feasible at all…

--

Best regards,

Dennis Schetinin

2013/4/6 stephane ducasse <stephane.ducasse@free.fr>

...

Hi 2013/4/1 Victor Stan <victor.stan@gmail.com>

...

Hi,

Are there any open source OODB's out there? Alternatives to GemStone?

I think there is no alternavise to GemStone.

I hope not :) Gemstone is good but an ecosystem with only one solution would look rather limited to me.

Because GemStome is not just data store. It is applicaton server where you work in multi user image system. Imagine single Pharo image which can work under different parallel VM instances (maybe running on different machines) which have concurrent access to same image objects, can commit it changes (save same image).

Sorry for such a late answer, I was away for some time and have just managed to break through the piles of e-mails. :) If I'm not mistaken, Oak is based on Riak, i.e. external storage engine. Actually, I was talking about Smalltalk-based solution. Why do you prefer an “externally supported backend”? -- Best regards, Dennis Schetinin 2013/4/8 Göran Krampe <goran@krampe.se>

Hey!

On 04/06/2013 04:40 PM, Dennis Schetinin wrote:

...

Why Pharo or Squeak don't have a framework (based on Fuel for example) that allows to control changes, execute transaction, save some parts of image instead of whole image etc.? This could be less efficient then GemStone, but loadable on demand, customizable and usable in smaller projects. Maybe there's such a project living already? Or is it too much for modern Smalltalk?

I already posted about such a project in this thread, Oak, why didn't you notice?:

http://goran.krampe.se/2012/**12/29/oak/<http://goran.krampe.se/2012/12/29/oak/>

It's not complaining. I know the answer: there's no usable persistence

...

solution because I didn't create it :) I just want to know if someone else thinks the same way as I do?

Feel free to help out with Oak. It is exactly what you are asking for.

regards, Göran

Yes Göran, I understand your point. -- Best regards, Dennis Schetinin 2013/4/23 Göran Krampe <goran@krampe.se>

On 04/22/2013 07:24 PM, Dennis Schetinin wrote:

...

Sorry for such a late answer, I was away for some time and have just managed to break through the piles of e-mails. :)

If I'm not mistaken, Oak is based on Riak, i.e. external storage engine. Actually, I was talking about Smalltalk-based solution. Why do you prefer an “externally supported backend”?

Yes, it uses Riak - although it "can" use other k/v stores, but we decided to focus on Riak for the moment to keep things simpler and to be able to use features of Riak in a more direct way.

Personally I would love to also make it work for HyperDex but that little project is on my back burner right now.

I actually prefer to have a popular, hardened and widely used industrial strength engine at the bottom. Our community is so small that building and maintaining the same level of confidence in a Smalltalk only system is very hard. And also, don't forget performance.

regards, Göran