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
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" <jtuchel@objektfabrik.de> An: "Any question about pharo is welcome" <pharo-users@lists.pharo.org> 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 <icjohnsoia@gmail.com>:
Hi All,
Thoughts of a purely OO nature?
:)
Torsten Bergmann <astares@gmx.de> 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
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 <icjohnsoia@gmail.com> wrote:
Hi All,
Thoughts of a purely OO nature?
:)
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 <icjohnsoia@gmail.com> wrote:
Hi All,
Thoughts of a purely OO nature?
:)
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 <offray.luna@mutabit.com> 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 <icjohnsoia@gmail.com> wrote:
Hi All,
Thoughts of a purely OO nature?
:)
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 <icjohnsoia@gmail.com> wrote:
Hi All,
Thoughts of a purely OO nature?
:)
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 <leuenberger@inf.unibe.ch> 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 <icjohnsoia@gmail.com> wrote:
Hi All,
Thoughts of a purely OO nature?
:)
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 <https://youtu.be/zdx28GnoSRQ> Cheers, Manuel
On 31 Dec 2017, at 11:19, Stephane Ducasse <stepharo.self@gmail.com> 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 <leuenberger@inf.unibe.ch> 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 <icjohnsoia@gmail.com> wrote:
Hi All,
Thoughts of a purely OO nature?
:)
Thanks manuel. On Wed, Jan 3, 2018 at 2:14 PM, Manuel Leuenberger <leuenberger@inf.unibe.ch> 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 <stepharo.self@gmail.com> 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 <leuenberger@inf.unibe.ch> 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 <icjohnsoia@gmail.com> wrote:
Hi All,
Thoughts of a purely OO nature?
:)
participants (9)
-
Hilaire -
Ian Ian -
Joachim Tuchel -
Manuel Leuenberger -
Offray Vladimir Luna Cárdenas -
Richard Sargent -
Stephan Eggermont -
Stephane Ducasse -
Torsten Bergmann