Can't figure out Cypher queries even when I duplicate what is in the docs.

[bytor99999]

My config doesn't look like that at all. What I took from the docs was

    <neo4j:config storeDirectory="${neo4j.location}"/>
    <neo4j:repositories base-package="com.perfectworldprogramming.eventgate"/>
    <tx:annotation-driven mode="proxy"/>

I don't think we should need to write more xml just to add one property. What about the <neo4j:config have an attribute for it instead.

Sorry, but this is partly what I am trying to show, is that unfortunately, the docs make too many assumptions.

I mean this in a nice way, but there can be a culture difference. You know us Americans, we want everything given to us on a silver platter with specific documentation laid out telling us everything.

If someone is a newbie like me that just wants to jump right into SDN, I will only read the SDN docs including my introduction to Neo4J and will expect that to be fully covered. Mainly because we know that SDN makes things so much simpler, that we don't have to spend even more time reading other docs to figure it all out. I modeled my app around the Cineasts app in the docs expecting it to just work, but found that there were many hidden gems not shown in the docs that were just as important to know and understand to make it work.

I hope you understand, I am not trying to be mean, or negative, or anything bad. I just want to make it better than how great it already is.

Mark

[MichaelHunger]

Your config covers the simplest case possible, the 80 percent case.

In the 20 percent case you have to do more (that involves store upgrades, auto-upgrading is also not an option b/c this is something that should be controlled). So upgrading it explicitly in a separate step/program would be sensible.

Probably it is cultural, but it is also about complexity and effort. So you don't want to have everything documented upfront b/c it would pollute the basic use-cases with too much detail. Same goes for the configuration, if we had every neo4-configuration option in the namespace it would have 30 or so attributes which confuses more than it helps.

So far people were ok with this approach. Also completely hiding that there is a full database system running under the hood makes not much sense as this would blur people's sense (full transparency is not the goal and also not useful).

Don't get me wrong I'm really thankful for the feedback, please continue to line out shortcomings in docs and configuration. Can you raise an issue for this? I think a sensible solution would be to provide a separate command line app within that just updates the store (on demand). And document this / put it in the exception message.

[bytor99999]

Yeah, if it was really bad, I wouldn't be sticking around. I am very fast to jump away from using projects that aren't great.

That is why I jumped away from ROO. I tried to keep as much code that ROO generated, but as each day goes by there is more and more I have ripped out. I have already removed using it, and pushed in all its code, but I have been deleting a lot of the pushed in code. The only code from ROO I still have left are the getters and setters in my domain objects and the pom file.

So, I am a still confused. If I use the configuration you posted, that will automatically upgrade my database whenever I upgrade Neo4j.

What is the part about creating a standalone application and running it from the command line part? I hope I don't have to do anything like that. Even if I change the structure of some Nodes and add new types of Nodes and Relationships, I don't think there is a schema or upgrade you have to do to your database, right?

Thanks

Mark

[MichaelHunger]

I meant: Upgrading from one store version to another (irreversible) is an ops-task, that should not be something that is done on the fly by the app, but consciously by a operator. That's why a simple tool (like the neo4j-shell) would be more sensible for this.

It is not about schema upgrades but store versions.

[bytor99999]

Thanks, I made the config change and finally found it in the docs, near the end sections.

Which issue to create? To create a command line script? Or, adding an attribute to

<neo4j:config storeDirectory="${neo4j.location}"/>

like update="true"

<neo4j:config storeDirectory="${neo4j.location}" update="true"/>



Mark

[MichaelHunger]

I'd say rather the command line script, as I said it is an ops operation (imho) upgrading internal store structures after a version bump.

[bytor99999]

But if you are upgrading via changing a pom.xml file and just changing the <properties><neo4j.version>1.6.RELEASE</neo4j.version></properties>

Then that isn't being done by operations, and typically done by developers before it is decided to upgrade and then maybe have operations do it on production.

Like in my case. I am a one man team, there ain't no operations team.

Mark