Smalltalk › Pharo › Pharo Smalltalk Users

Object Persistence

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

13 messages Options

Ian Ian

Object Persistence

Hi All,

Thoughts of a purely OO nature?

:)

Richard Sargent

Re: Object Persistence

Administrator

GemStone/S, of course!

On Dec 25, 2017 01:44, "Ian Ian" <[hidden email]> wrote:

Hi All,

Thoughts of a purely OO nature?

:)

HilaireFernandes

Re: Object Persistence

In reply to this post by Ian Ian

Fuel (present in the image) is nice, but not compatible from one image
version to another one.

Hilaire

Le 25/12/2017 à 10:43, Ian Ian a écrit :
> Hi All,
>
> Thoughts of a purely OO nature?
>
> :)

--
Dr. Geo
http://drgeo.eu

http://drgeo.eu

jtuchel

Re: Object Persistence

In reply to this post by Ian Ian

Wasn’t there an attempt to port Magma over from Squeak? That would sound like a nice alternative. Or Gemstone, of course.

> Am 25.12.2017 um 10:43 schrieb Ian Ian <[hidden email]>:
>
> Hi All,
>
> Thoughts of a purely OO nature?
>
> :)

Torsten Bergmann

Re: Object Persistence

Hi,

with Voyage you can already use easy persistence in an OO way - with tiny (P)UnQlite up to Mongo.

Check https://github.com/pharo-nosql

Or you use Gemstone.

For a full Magma version on Pharo:
I doubt that will happen as Chris Muller was and still is more oriented towards Squeak as
development platform. He is the author of Magma and beside the port it would cost him
(or anyone who would do such a port) more effort to maintain another Pharo specific version.

But maybe a Pharo client for a Squeak based Magma server is possible - with a Voyage wrapper.

Bye
T.

> Gesendet: Montag, 25. Dezember 2017 um 12:54 Uhr
> Von: "Joachim Tuchel" <[hidden email]>
> An: "Any question about pharo is welcome" <[hidden email]>
> Betreff: Re: [Pharo-users] Object Persistence
>
> Wasn’t there an attempt to port Magma over from Squeak? That would sound like a nice alternative. Or Gemstone, of course.
>
> > Am 25.12.2017 um 10:43 schrieb Ian Ian <[hidden email]>:
> >
> > Hi All,
> >
> > Thoughts of a purely OO nature?
> >
> > :)
>
>
>

Stephane Ducasse-3

Re: Object Persistence

In reply to this post by Ian Ian

the author of omnibase told me that he always wanted to port it to
Pharo. But may be someone should do it.
There is also VOSS that is open source even if GPL that could be
ported to pharo but this is an effort too.

Stef

On Mon, Dec 25, 2017 at 10:43 AM, Ian Ian <[hidden email]> wrote:
> Hi All,
>
> Thoughts of a purely OO nature?
>
> :)

Offray Vladimir Luna Cárdenas-2

Re: Object Persistence

But if VOSS is GPL, that doesn't imply that, when ported, all Pharo
could become GPL, as discussed time and again in the list?

Cheers,

Offray

On 25/12/17 10:01, Stephane Ducasse wrote:

> the author of omnibase told me that he always wanted to port it to
> Pharo. But may be someone should do it.
> There is also VOSS that is open source even if GPL that could be
> ported to pharo but this is an effort too.
>
> Stef
>
> On Mon, Dec 25, 2017 at 10:43 AM, Ian Ian <[hidden email]> wrote:
>> Hi All,
>>
>> Thoughts of a purely OO nature?
>>
>> :)
>

Manuel Leuenberger

Re: Object Persistence

In reply to this post by Ian Ian

I’ve always liked Neo4j to persist object graphs. Also has a nice query language. The database is not fool-proof (isolation issues, out of memory on expensive queries), but works fine for analytics.

> On 25 Dec 2017, at 10:43, Ian Ian <[hidden email]> wrote:
>
> Hi All,
>
> Thoughts of a purely OO nature?
>
> :)

Stephan Eggermont-3

Re: Object Persistence

In reply to this post by Torsten Bergmann

Torsten Bergmann <[hidden email]> wrote:
> For a full Magma version on Pharo:
> I doubt that will happen as Chris Muller was and still is more oriented towards Squeak as
> development platform. He is the author of Magma and beside the port it would cost him
> (or anyone who would do such a port) more effort to maintain another
> Pharo specific version.

A Magma version on Pharo is perfectly doable, and Chris has always said
he'd be willing to support anyone willing to do the port. It is a
significant amount of work, and only makes sense when someone is willing to
commit to maintaining it on successive Pharo versions, i.e. has a
commercial use case that can afford to upgrade it. The first port will be
significant as it needs to take into account a few years of upgrades and
deprecations. It is also a job not so suited to a student as it requires a
lot of email history digging and experience with Squeak and Pharo.

Stephan

Stephane Ducasse-3

Re: Object Persistence

In reply to this post by Offray Vladimir Luna Cárdenas-2

We could talk to the guy to see if he wants to revisit the license.
and you can decide to load GPL in your app and be happy.
I hope that omnibase will be ported to pahro in the future.

On Tue, Dec 26, 2017 at 9:30 PM, Offray Vladimir Luna Cárdenas
<[hidden email]> wrote:

> But if VOSS is GPL, that doesn't imply that, when ported, all Pharo
> could become GPL, as discussed time and again in the list?
>
> Cheers,
>
> Offray
>
> On 25/12/17 10:01, Stephane Ducasse wrote:
>> the author of omnibase told me that he always wanted to port it to
>> Pharo. But may be someone should do it.
>> There is also VOSS that is open source even if GPL that could be
>> ported to pharo but this is an effort too.
>>
>> Stef
>>
>> On Mon, Dec 25, 2017 at 10:43 AM, Ian Ian <[hidden email]> wrote:
>>> Hi All,
>>>
>>> Thoughts of a purely OO nature?
>>>
>>> :)
>>
>
>

Stephane Ducasse-3

Re: Object Persistence

In reply to this post by Manuel Leuenberger

Hi manuel

what kind of queries can we express?
Can be get select node?
Now out of memory is a read falg for me (for moose because we do that
all the time).

Stef

On Tue, Dec 26, 2017 at 10:03 PM, Manuel Leuenberger
<[hidden email]> wrote:

> I’ve always liked Neo4j to persist object graphs. Also has a nice query language. The database is not fool-proof (isolation issues, out of memory on expensive queries), but works fine for analytics.
>
>> On 25 Dec 2017, at 10:43, Ian Ian <[hidden email]> wrote:
>>
>> Hi All,
>>
>> Thoughts of a purely OO nature?
>>
>> :)
>
>

Manuel Leuenberger

Re: Object Persistence

Hi Stef,

The Neo4j Cypher queries express a subgraph/path that you want to match in the big graph (nodes and edges with attributes). No fragmentation due to normalization etc., so no joins, it’s more like a regex matcher:

MATCH p=(x:PERSON)-[:KNOWS*]->(:PERSON)

WHERE x.name = 'John'

RETURN p;

Will give you the graph of all persons John knows and all the persons they know (transitive closure). You can also combine multiple queries that one processes the result of the other (pipes and filters). See https://neo4j.com/developer/cypher-query-language/

OutOfMemory only happens if your query selects more data (at any point) than you have memory, as the query execution happens entirely in memory, there seems to be no flush do disk. But there are ways to work around this (albeit resulting in uglier partitioned queries).

You can see it in action for my KOWALSKI tool, collecting API clients and extracting call graphs: https://youtu.be/zdx28GnoSRQ

Cheers,

Manuel

On 31 Dec 2017, at 11:19, Stephane Ducasse <[hidden email]> wrote:

Hi manuel

what kind of queries can we express?
Can be get select node?
Now out of memory is a read falg for me (for moose because we do that
all the time).

Stef

On Tue, Dec 26, 2017 at 10:03 PM, Manuel Leuenberger
<[hidden email]> wrote:
I’ve always liked Neo4j to persist object graphs. Also has a nice query language. The database is not fool-proof (isolation issues, out of memory on expensive queries), but works fine for analytics.

On 25 Dec 2017, at 10:43, Ian Ian <[hidden email]> wrote:

Hi All,

Thoughts of a purely OO nature?

:)

Stephane Ducasse-3

Re: Object Persistence

Thanks manuel.

On Wed, Jan 3, 2018 at 2:14 PM, Manuel Leuenberger
<[hidden email]> wrote:

> Hi Stef,
>
> The Neo4j Cypher queries express a subgraph/path that you want to match in
> the big graph (nodes and edges with attributes). No fragmentation due to
> normalization etc., so no joins, it’s more like a regex matcher:
>
> MATCH p=(x:PERSON)-[:KNOWS*]->(:PERSON)
> WHERE x.name = 'John'
> RETURN p;
>
> Will give you the graph of all persons John knows and all the persons they
> know (transitive closure). You can also combine multiple queries that one
> processes the result of the other (pipes and filters). See
> https://neo4j.com/developer/cypher-query-language/
>
> OutOfMemory only happens if your query selects more data (at any point) than
> you have memory, as the query execution happens entirely in memory, there
> seems to be no flush do disk. But there are ways to work around this (albeit
> resulting in uglier partitioned queries).
>
> You can see it in action for my KOWALSKI tool, collecting API clients and
> extracting call graphs: https://youtu.be/zdx28GnoSRQ
>
> Cheers,
> Manuel
>
> On 31 Dec 2017, at 11:19, Stephane Ducasse <[hidden email]> wrote:
>
> Hi manuel
>
> what kind of queries can we express?
> Can be get select node?
> Now out of memory is a read falg for me (for moose because we do that
> all the time).
>
> Stef
>
>
> On Tue, Dec 26, 2017 at 10:03 PM, Manuel Leuenberger
> <[hidden email]> wrote:
>
> I’ve always liked Neo4j to persist object graphs. Also has a nice query
> language. The database is not fool-proof (isolation issues, out of memory on
> expensive queries), but works fine for analytics.
>
> On 25 Dec 2017, at 10:43, Ian Ian <[hidden email]> wrote:
>
> Hi All,
>
> Thoughts of a purely OO nature?
>
> :)
>
>
>
>
>