On Mon, Sep 7, 2015 at 6:46 PM, wrote:
> Hi Nigel, hi Mathias,
>
> Thanks for the suggestions !
>
> > You should try with Neo4j 2.2.5
> Do you think to a specific fix released in this version which may help
> here ?
> Anyway, I think I'll upgrade in a close future.
>
Thanks Mathias ! I've downloaded 2.2.5 and I will upgrade the server in the
coming days.
FWIW, the modification of the submit() method doesn't sound like the way to
go. If the scenario described in my previous email is correct, this
modification can't fix the problem (stupid me, episode 2 :D).
Mathias,
I've just tried to install 2.2.5 on my dev server.
It seems that store version of my db is v0.A.4 (neo4j 2.2.0) but neo4j
2.2.5 expects v0.A.3.
So, it doesn't sound like an option for me. I fear that I'll have to wait
for a stable 2.3.0 to upgrade my store to v5.
--
You received
You should try with Neo4j 2.2.5
On Sunday, September 6, 2015 at 8:06:04 PM UTC+2, lauren...@gmail.com wrote:
>
> Hi Nigel,
>
> Thanks for the answer. Very much appreciated and always good to get a
> confirmation from the expert :)
> I'm still investigating the case but progress is very slow
Hi Nigel,
Thanks for the answer. Very much appreciated and always good to get a
confirmation from the expert :)
I'm still investigating the case but progress is very slow because I can't
reproduce the problem with "artificial" simple code.
For now, my intuition is that a cypher query or a
Batches should never be reused and a new one will need to be created for
each unit of work. Also, *run* does not spot exceptions, unlike *execute*
since it does not decode the output from the server (including exceptions).
This makes it slightly faster but it a tradeoff against using *execute*.
After hours spent on trying to troubleshoot the problem, it seems the issue
comes from the BatchWrite class provided by py2neo.
For now, it seems that crreating a new instance of BatchWrite at each
iteration of the process and calling run() method instead of submit() may
help to solve the