Very good, thanks a lot.
On 10/11/11 1:21 AM, chris.gioran [via Neo4j Community Discussions] wrote:
> Hi Thibaut,
>
> we currently have a working solution that changes the commitCows()
> call from a during commit call to an afterCompletion synchronization.
> It seems to work fine and your test cas
Hi Thibaut,
we currently have a working solution that changes the commitCows()
call from a during commit call to an afterCompletion synchronization.
It seems to work fine and your test case passes. Essentially it roots
out the implicit assumption in that part of the kernel that he
transaction shou
Hi Chris.
I don't mean to pressure, I write OSS myself and I know time is
available whenever it is, so i just have some quick questions about this
issue.
Basically I just need to decided whether to shelf this feature of our
project for now or if i can get any idea on how much work / how long it
Thanks Chris, that's exactly the issue I had in our real system, I
actually did notice that null Tx in the cow map code while stepping
through with the debugger.
I don't really see why this is happening however, let me know if you
think it's more of an atomikos issue, or if it can be dealt with
This appears to be a different issue, having to do with the
implementation of Atomikos. From some preliminary testing it seems
that during commit the transaction returned by Atomikos'
TransactionManager#getTransaction() is null, which makes commiting of
the property COW maps to fail, making impossi
OK, I've modified the unit test and it shows something strange now ...
assuming I'm not just too tired and messed up again :)
So the previous test, corrected, passes fine, but now after the first
transaction is commited, i start a second one where i do the same exact
check (node by prop)
see:
You are right, was just using that in this (poor) unit test I made
quickly late last week, it's not used in the real code.
So the unit test does work and does not have the issue I have in the
real and much more complex code.
I guess I'll try to bring more of it in this unit test until i break i
The implicit key is "_id_" but that's an implementation detail and shouldn't
be used to assert correctness of the index in unit tests.
2011/10/8 Thibaut Colar
> Actually you are right, seems like "id" is the only one that fails ... i
> really thought that was implicitly created, could it be poss
Actually you are right, seems like "id" is the only one that fails ... i
really thought that was implicitly created, could it be possible than
somehow it should be but doesn't when using the transaction manager ?
On 10/8/11 11:41 AM, Thibaut Colar wrote:
> Right, id is an implicit field ... work
Right, id is an implicit field ... works when not in transaction.
If i remove that test, then I fail on the later index.get.
As far as deleting the db, it's not in my test, but i removed the folder
in y real code and manually before running the test.
On 10/8/11 11:10 AM, Rick Bullotta wrote:
> I
If I remember correctly, neo has an implicit field on each index, and the name
is either "id" or "_id".
On Oct 8, 2011, at 1:58 PM, "Chris Gioran"
wrote:
> Hi Thibaut,
>
> I noticed the following snippet in your test case code:
>
>long id = node.getId();
>node.setProperty("t
Hi Thibaut,
I noticed the following snippet in your test case code:
long id = node.getId();
node.setProperty("testProp", "test");
index.add(node, "testProp", "test");
Assert.assertEquals(node.getProperty("testProp"), "test");
// Lookup By id
Asser
I've been trying to make this work for a few days but while it mostly works,
the Lucene index just won't.
We have a fairly complex setup including neo4j, mysql, mongo and JMS ad
trying to do transactions accross all that with Atomikos.
Since that is quite complex, I've made a smaller unit test ju
13 matches
Mail list logo
