Index with the same name but different config exists!

[Bruno Mendola]

Hi,

I'm facing a few problems while trying to integrate Neo4j and Spring Data Graph in a new application:

starting with an empty DB and trying to just save a new entity, it throws an exception saying "Index with the same name but different config exists!".

Here is the full stacktrace of the exception: http://pastebin.com/AYfwe5LS

And this is the entity class: http://pastebin.com/1EfFR20V

As you can see, there is the following indexed field that is generating the exception:

@Indexed(indexType=IndexType.FULLTEXT, indexName="users")
String username;

I really don't know what may be the reason for this not working, I'm quite sure that my code is ok.

Do you know what I can do to solve the problem?

Kind regards,
Bruno

[Peter Neubauer]

Do you have some class called User? Might be that the naming
convention is coming in the way?

Cheers,

/peter neubauer

G:  neubauer.peter
S:  peter.neubauer
P:  +46 704 106975
L:   http://www.linkedin.com/in/neubauer
T:   @peterneubauer

Neo4j 1.6 released                 - dzone.com/6S4K
The Neo4j Heroku Challenge   - http://neo4j-challenge.herokuapp.com/

[Michael Hunger]

Did you run the app against the same database before without the "fulltext" parameter?
So that the neo4j server created an "exact" index and you changed the index-type later?

michael

[Bruno Mendola]

Il giorno sabato 24 marzo 2012 22:06:13 UTC+1, Peter Neubauer ha scritto:

Do you have some class called User? Might be that the naming
convention is coming in the way?

The class which contains this indexed field is called User, but I also tried to rename the index with very different names... it is not the index name, definitely.

[Bruno Mendola]

Il giorno sabato 24 marzo 2012 22:17:56 UTC+1, Michael Hunger ha scritto:

Did you run the app against the same database before without the "fulltext" parameter?
So that the neo4j server created an "exact" index and you changed the index-type later?

I delete the database (deleting the data/graph.db directory) and reboot neo4j just before starting the app, the exception is thrown on the first user registration.

When I check on the db with webadmin I see that the node is created, but not with all the attributes it should have. And the "users" index also is present, but it throws the exception when for some reason Neo4j tries to create it twice, and with a different configuration, during the same save operation.

Now I'm suspecting a bug in the REST API that I use to connect to Neo4j on a remote server, because as you can see the exception is thrown by the RestAPI.createIndex() method. Tomorrow I will try with a db on my local machine.

[Michael Hunger]

When you check the db with webadmin, which config does it have?

Perhaps you really encountered a bug with the Rest-DB-Wrapper, if so we'll fix it.

Cheers

Michael

[Mattias Persson]

Yup, it seems the index has already been created... maybe with the default config which is an exact index. When you try to get/create the index for the users in SDN specifying type:fulltext it will fail because that index was created with another config. So figuring out where it's created first is the next step.

2012/3/25 Michael Hunger <michael...@neotechnology.com>

--
Mattias Persson, [mat...@neotechnology.com]
Hacker, Neo Technology
www.neotechnology.com

[Bruno Mendola]

Il giorno domenica 25 marzo 2012 12:45:33 UTC+2, Mattias Persson ha scritto:

Yup, it seems the index has already been created... maybe with the default config which is an exact index. When you try to get/create the index for the users in SDN specifying type:fulltext it will fail because that index was created with another config. So figuring out where it's created first is the next step.

It is strange, because the only operation I do on the DB is the save of the User node that generate the exception.

I double checked the dependencies and I have the following libraries in my webapp:

• lucene-core-3.5.0.jar
• neo4j-1.6.1.jar
• neo4j-cypher-1.6.1.jar
• neo4j-cypher-dsl-1.6.M02.jar
• neo4j-graph-algo-1.6.1.jar
• neo4j-graph-matching-1.6.1.jar
• neo4j-jmx-1.6.1.jar
• neo4j-kernel-1.6.1.jar
• neo4j-lucene-index-1.6.1.jar
• neo4j-rest-graphdb-1.6.jar
• neo4j-udc-1.6.1.jar

they are all coming automagically from Maven, so I assume that the versions are right.

I also tried to use the local connector to Neo4j, to be sure that this isn't a bug on the REST API... well, the error message is different but has the same meaning (immo the error message should be the same, for consistency).

Doing some debug I noticed that the call to the creation of the index, during the first save operation, checks for an existing config of the index with that name and finds two configs, which differ for the to_lower_case parameter that should come automatically with type=fulltext, but on the first config is not present. That generates the exception.

Anyway, I got it work removing all the parameters from the @Indexed annotation. But it's not as it is supposed to work, is it?

The indexes are now created without exceptions at the first save, with the default configuration, and named as the class they belong to.

The worst part is that now I have nodes on the DB that are not indexed as I want, not fulltext, case insensitive or unique.

I hope I gave you some hint to solve this issue, or maybe to find out that I'm doing something wrong :)

Bruno

[Peter Neubauer]

Bruno,
the tests for this are in
https://github.com/SpringSource/spring-data-neo4j . Could you, if you
have the time, see if you can extend one test to make it fail the way
you experience, so we can fix it and you can raise an issue?

Cheers,

/peter neubauer

G:  neubauer.peter
S:  peter.neubauer
P:  +46 704 106975
L:   http://www.linkedin.com/in/neubauer
T:   @peterneubauer

Neo4j                                - Graphs rule.
Program or be programmed - Computer Literacy for kids.
http://foocafe.org/#CoderDojo

[Michael Hunger]

Bruno,

thanks for pointing that out. It might be sensible then to take the implicitly added index configurations into account (like to_lower_case=true)

I really wonder why this never showed up in any of our tests which also exercise fulltext-indexes both in embedded as well as in REST mode.

Could you please raise an issue at http://spring.neo4j.org/issues so that it doesn't get lost?

Thanks a lot

Michael