Hi,
I have my own transaction implementation that is associated with the current
thread. Transactions have a dictionary to hold arbitrary objects (such as
revision objects) as "transactional context". Additionally, lifecycle listeners
can be registered that can take action before / after begin
Hi Peter,
sorry to pick up this old thread, but you mentioned that in your system
revisions are automatically created with every transaction. How do you
do this? Hooks, aspects, weaving, magic?
Thanks and best regards,
Georg
> Hi,
>
> I have also built some versioning concept on Neo before.
>
On Wed, May 20, 2009 at 3:03 PM, Peter Haensgen wrote:
>
> If you can't copy them, because you have too many relationships, you
> need to separate them into 2 groups somehow: "added" and "removed".
> The "added" group could be just the plain relationship, the "removed"
> group could be a property
Hi again,
> The way you have modeled things, are all active relationships at a
> particular version present at that version node, or is the set of
> relationships made up from all version nodes all the way back to the
first
> version of an object.
in my case, all relationships are copied. For my
Hi Peter,
The separation of identity and version of objects is a good point.
The way you have modeled things, are all active relationships at a
particular version present at that version node, or is the set of
relationships made up from all version nodes all the way back to the first
version of a
Hi,
I have also built some versioning concept on Neo before.
Essentially, my solution is based on two kinds of objects:
- VersionedObject represents the identity of something. It references
ObjectVersions.
- ObjectVersion represents a version of the object, there can be many
and they point to th
On 19 May 2009, at 20:03, Tobias Ivarsson wrote:
> Since you are planning to publish your code under AGPL on github, do
> you mind me asking what the system you are building is doing?
I'm afraid I can't talk about the application yet (we're going to get
a commercial license for Neo4j). I just
On Tue, May 19, 2009 at 8:36 PM, Martin Kleppmann
wrote:
> On 19 May 2009, at 16:47, Tobias Ivarsson wrote:
> > I feel that this is something that would occur in more applications,
> > so I
> > thing that it would be a good idea to come up with, and document, a
> > design
> > pattern for how to mo
On 19 May 2009, at 16:47, Tobias Ivarsson wrote:
> I feel that this is something that would occur in more applications,
> so I
> thing that it would be a good idea to come up with, and document, a
> design
> pattern for how to model different versions of entities in Neo4j.
As it happens, this
Hi again,
Perhaps I should elaborate a bit on the structure of problem I am
trying to solve, to give you guys a better understanding of what I
want to do.
I have a number of entity types: A,B,C,D
A relates to multiple B, each B relates to zero or one A
B,C and D form a complicated relationship wh
On Tue, May 19, 2009 at 6:50 PM, Peter Ferne wrote:
>
>
> At the risk of being a pedant and/or teaching you to suck eggs I have
> to point out that the idea of design patterns is that they codify
> existing best practice, they document tried and tested solutions, and
> so talking about wanting to "
On 19 May 2009, at 16:47, Tobias Ivarsson wrote:
> It turns out that the actual structure needed for the version
> management is not
> trivial.
>
> I feel that this is something that would occur in more applications,
> so I
> thing that it would be a good idea to come up with, and document, a
Hi Neo4j followers and experts,
I have been thinking about how to model entities with versions in Neo4j a
few times, but never had opportunity to implement such a thing. Now I find
myself in a project where every version of everything is relevant. It turns
out that the actual structure needed for
13 matches
Mail list logo
