Open Source OODB's

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
17 messages Options
Reply | Threaded
Open this post in threaded view
|

Open Source OODB's

Victor
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: 
Reply | Threaded
Open this post in threaded view
|

Re: Open Source OODB's

Paul DeBruicker
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
>


Reply | Threaded
Open this post in threaded view
|

Re: Open Source OODB's

Paul DeBruicker
In reply to this post by Victor
And magma.


Can't forget about magma

http://wiki.squeak.org/squeak/2665




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
>


Reply | Threaded
Open this post in threaded view
|

Re: Open Source OODB's

Victor
In reply to this post by Paul DeBruicker
Frankly, this project looks like joke...

Victor Stan

Schedule me: 


On Sun, Mar 31, 2013 at 9:40 PM, Paul DeBruicker <[hidden email]> 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
>



Reply | Threaded
Open this post in threaded view
|

Re: Open Source OODB's

Victor
Magma seems to have some potential...

Victor Stan

Schedule me: 


On Sun, Mar 31, 2013 at 11:25 PM, Victor Stan <[hidden email]> wrote:
Frankly, this project looks like joke...

Victor Stan

Schedule me: 


On Sun, Mar 31, 2013 at 9:40 PM, Paul DeBruicker <[hidden email]> 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
>




Reply | Threaded
Open this post in threaded view
|

Re: Open Source OODB's

Göran Krampe
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.

Reply | Threaded
Open this post in threaded view
|

Re: Open Source OODB's

Denis Kudriashov
In reply to this post by Victor
Hi
2013/4/1 Victor Stan <[hidden email]>
Hi, 

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

I think there is no alternavise to GemStone. 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).

Reply | Threaded
Open this post in threaded view
|

Re: Open Source OODB's

Victor
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!

Victor Stan

Schedule me: 


On Mon, Apr 1, 2013 at 6:48 AM, Denis Kudriashov <[hidden email]> wrote:
Hi

2013/4/1 Victor Stan <[hidden email]>
Hi, 

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

I think there is no alternavise to GemStone. 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).


Reply | Threaded
Open this post in threaded view
|

Re: Open Source OODB's

drush66
On Fri, Apr 5, 2013 at 3:58 AM, Victor Stan <[hidden email]> 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:



Davorin Rusevljan

Reply | Threaded
Open this post in threaded view
|

Re: Open Source OODB's

stephane ducasse
In reply to this post by Denis Kudriashov


Hi
2013/4/1 Victor Stan <[hidden email]>
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).


Reply | Threaded
Open this post in threaded view
|

Re: Open Source OODB's

Dennis Schetinin
+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 <[hidden email]>


Hi
2013/4/1 Victor Stan <[hidden email]>
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).



Reply | Threaded
Open this post in threaded view
|

Re: Open Source OODB's

EstebanLM
Hi, 

for smaller projects you have: 

- the image it self :)
- ... and I'm sure there are others :)

Esteban

On Apr 6, 2013, at 4:40 PM, Dennis Schetinin <[hidden email]> 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 <[hidden email]>


Hi
2013/4/1 Victor Stan <[hidden email]>
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).




Reply | Threaded
Open this post in threaded view
|

Re: Open Source OODB's

Göran Krampe
In reply to this post by Dennis Schetinin
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/

> 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

Reply | Threaded
Open this post in threaded view
|

Re: Open Source OODB's

Dennis Schetinin
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 <[hidden email]>
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/


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


Reply | Threaded
Open this post in threaded view
|

Re: Open Source OODB's

Dennis Schetinin
In reply to this post by EstebanLM
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 <[hidden email]>
Hi, 

for smaller projects you have: 

- the image it self :)
- ... and I'm sure there are others :)

Esteban

On Apr 6, 2013, at 4:40 PM, Dennis Schetinin <[hidden email]> 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 <[hidden email]>


Hi
2013/4/1 Victor Stan <[hidden email]>
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).





Reply | Threaded
Open this post in threaded view
|

Re: Open Source OODB's

Göran Krampe
In reply to this post by Dennis Schetinin
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

Reply | Threaded
Open this post in threaded view
|

Re: Open Source OODB's

Dennis Schetinin
Yes Göran, I understand your point.


--

Best regards,


Dennis Schetinin



2013/4/23 Göran Krampe <[hidden email]>
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