2009/6/25 Symeon (Akis) Papadopoulos :
> [My apologies for insisting on this issue.]
>> There's (at least) two solutions to this problem. One is that, as you
>> suggest, to have the iterator wrap its methods in transactions in
>> addition to the code that returns the iterator (look at
>> org.neo4j.
[My apologies for insisting on this issue.]
> There's (at least) two solutions to this problem. One is that, as you
> suggest, to have the iterator wrap its methods in transactions in
> addition to the code that returns the iterator (look at
> org.neo4j.util.TxIterator in neo-utils component). This
On Thu, Jun 25, 2009 at 10:31 AM, Symeon (Akis) Papadopoulos wrote:
>
> Currently, according to the Design Guide of Neo4j, the Model is defined
> in a Neo4j-agnostic way and only the implementations of the defined
> interfaces (e.g. CustomerImpl, OrderImpl) are Neo4j-dependent. In case I
> transfe
Thank you for your prompt answer. See one further question regarding
your second suggestion.
> Another (and probably better and more logical) is to manage your
> transactions at a slightly higher level. One example is an MVC model
> where it'd be a good idea to put your transaction handling in the
4 matches
Mail list logo
