Indeed! All tests pass! Thank you!
On Tuesday, October 28, 2014 9:52:22 AM UTC+1, Andrey Lomakin wrote:
Fixed.
On Fri, Oct 24, 2014 at 12:21 PM, Emanuele Milani milani.em...@gmail.com
javascript: wrote:
Thank you very much!
On Friday, October 24, 2014 9:49:11 AM UTC+2, Andrey Lomakin
Hi Andrey,
I tried the same code with 2.0-SNAPSHOT (build 363), but unfortunetely the
problem is still there. Could you also replicate it?
I also tried to check if my local cache is enabled, but I only found in the
docs that it should be enabled by default.
I am now adding a small maven project
[clean] [-U] test -Dtest=OrientTests*
Thank you in advance!
On Wednesday, October 22, 2014 11:48:40 AM UTC+2, Emanuele Milani wrote:
Hi Andrey,
I tried the same code with 2.0-SNAPSHOT (build 363), but unfortunetely the
problem is still there. Could you also replicate it?
I also tried to check
Hi all!
I am in the process of debugging an application based on OrientDB (2.0M2).
The problem I am facing are some OConcurrentModificationException. The
issue appears with both the memory and the plocal storage engines (I
did not try remote). It looks they are caused by the fact that multiple
%2Forientechnologies%2Forientdb%2Fissues%2F1894sa=Dsntz=1usg=AFQjCNFOswse4xl3Bc3qu068Y3Q-XXGOfw
On Fri, Mar 7, 2014 at 4:59 PM, Emanuele Milani
milani.em...@gmail.comjavascript:
wrote:
Dear all,
This same message is posted on both the OrientDB and Gremlin-users
groups, as I do not know whether
Dear all,
This same message is posted on both the OrientDB and Gremlin-users groups,
as I do not know whether this issue is related to Blueprints or OrientDB.
For quite some time I have been using KeyIndexes (as in KeyIndexableGraph)
with an embedded (database url starting with (p)local:)
it is taking
more time than I thought.
Thanks again for your help!
On Monday, February 17, 2014 1:36:31 PM UTC+1, Andrey Lomakin wrote:
Hi,
Sorry I did not get, what is your problem, could you provide example ?
On Fri, Feb 14, 2014 at 5:49 PM, Emanuele Milani
milani.em
Hi all!
In my application I am trying to batch transactions, so that actual
commit() are called every k (batch size) virtual commit(). The idea is to
trade-off between high granularity commits and better perfromance.
The problem is that the code performs a lookup for a node which may not
have