Hi, this is great, I was still holding my breath and at first didnt even 
notice, then I got the snapshot and changed classpaths in my project to 
use 1.5.m, when I noticed the following error

org.neo4j.graphdb.TransactionFailureException: Could not create data 
source [nioneodb], see nested exception for cause of error
org.neo4j.kernel.impl.transaction.TxModule.registerDataSource(TxModule.java:153)
org.neo4j.kernel.GraphDbInstance.start(GraphDbInstance.java:112)
        at 
org.neo4j.kernel.EmbeddedGraphDbImpl.<init>(EmbeddedGraphDbImpl.java:190)
        at 
org.neo4j.kernel.EmbeddedGraphDatabase.<init>(EmbeddedGraphDatabase.java:80)
...
Caused by: 
org.neo4j.kernel.impl.storemigration.UpgradeNotAllowedByConfigurationException: 
To enable automatic upgrade, please set allow_store_upgrade in 
configuration properties
        at 
org.neo4j.kernel.impl.storemigration.ConfigMapUpgradeConfiguration.checkConfigurationAllowsAutomaticUpgrade(ConfigMapUpgradeConfiguration.java:41)
        at 
org.neo4j.kernel.impl.storemigration.StoreUpgrader.attemptUpgrade(StoreUpgrader.java:50)
        at 
org.neo4j.kernel.impl.nioneo.store.NeoStore.tryToUpgradeStores(NeoStore.java:127)
        at 
org.neo4j.kernel.impl.nioneo.store.NeoStore.verifyCorrectTypeDescriptorAndVersion(NeoStore.java:98)
        at 
org.neo4j.kernel.impl.nioneo.store.CommonAbstractStore.loadStorage(CommonAbstractStore.java:196)
        at 
org.neo4j.kernel.impl.nioneo.store.CommonAbstractStore.<init>(CommonAbstractStore.java:104)
        at 
org.neo4j.kernel.impl.nioneo.store.AbstractStore.<init>(AbstractStore.java:120)
        at org.neo4j.kernel.impl.nioneo.store.NeoStore.<init>(NeoStore.java:72)
        at 
org.neo4j.kernel.impl.nioneo.xa.NeoStoreXaDataSource.<init>(NeoStoreXaDataSource.java:137)
        at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
        at 
sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)
        at 
sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
        at java.lang.reflect.Constructor.newInstance(Constructor.java:513)
        at 
org.neo4j.kernel.impl.transaction.XaDataSourceManager.create(XaDataSourceManager.java:75)
        at 
org.neo4j.kernel.impl.transaction.TxModule.registerDataSource(TxModule.java:147)
        ... 24 more


which tells me to allow the neo-store to be updated. That spooked me so 
much that I didnt yet try it in earnest, focusing instead on rewriting 
my app to work without thread-interrupts because that was apparently 
messing with lucene, and trying to find the reason why the 
worker-threads' transactions always keep deadlocking... as much as I 
desired that cypher-feature with the RelationshipIndexLookup, there are 
work-arounds, but I'll get around to testing it sometime soon.

Before I do upgrade the store,

   39 MB  neostore.nodestore.db
  412 MB  neostore.propertystore.db
4315 MB  neostore.propertystore.db.arrays
1857 MB  neostore.propertystore.db.strings
1090 MB  neostore.relationshipstore.db
plus 1.6GB of indices,

any idea how long such a neostore-upgrade might take from 1.4.1. to that 
1.5.snapshot? like seconds, minutes, hours, or worse?


Am 02.10.2011 19:25, schrieb Andres Taylor:
> And now it's ready.
>
> If you are using SNAPSHOT, please update your dependencies, and check it
> out.
> http://docs.neo4j.org/chunked/snapshot/query-start.html#start-relationship-by-index-lookup
>
> Thanks again for providing feedback. It's much more fun coding when I know
> someone is using it.
>
> Andrés
>
> On Fri, Sep 30, 2011 at 10:37 AM, Andres Taylor<
> andres.tay...@neotechnology.com>  wrote:
>
>> Hey!
>>
>> This is something that has been planned since the very first iteration of
>> Cypher, but no-one seemed to need it, so I have pushed it in front of me.
>>
>> Now we seem to have an user that wants it, so I'll add it.
>>
>> Don't hold your breath though - it'll be ready when it's ready.
>>
>> Andrés
>>
>>
>> On Thu, Sep 29, 2011 at 1:10 PM, st.pa<st...@web.de>  wrote:
>>
>>> hi.
>>> when i use a cypher query to get the queued nodes associated via
>>> queue-relationships to a repository-node which has several million other
>>> relationships then it takes about six minutes to fill that result list:
>>>
>>> <pre>
>>> List<Node>  list = new ArrayList<Node>();
>>> StringBuffer s = new StringBuffer();
>>> s.append("START repository = (");
>>> s.append((Long) controller.getRepositoryNode().getId());
>>> s.append(") MATCH (repository)-[:");
>>> s.append(Rels.REL_REPOSITORY_QUEUE);
>>> s.append("]->(node) RETURN node ORDER BY node.");
>>> s.append(Keys.KEY_TIMESTAMP);
>>> s.append(" SKIP ");
>>> s.append(Integer.toString(offset));
>>> s.append(" LIMIT ");
>>> s.append(Integer.toString(buffersize));
>>> Log.log(s.toString());
>>> Query query = this.parser.parse(s.toString());
>>> ExecutionResult result = this.engine.execute(query);
>>> Iterator<Node>  iterator = result.columnAs("node");
>>> while (iterator.hasNext()) {
>>>    list.add(iterator.next());
>>> }
>>> </pre>
>>>
>>> but when i directly query the relationshipIndex containing all
>>> queue-relationships and assuming that sorting by timestamp is equivalent
>>> to sorting by node-ids then it completes in just half a minute, which is
>>> a dozen times faster:
>>>
>>> <pre>
>>> List<Node>  list = new ArrayList<Node>();
>>> IndexHits<Relationship>  hits =
>>> controller.getRelationIndexRepositoryUrlQueue().query(
>>>    Keys.KEY_TYPE,Rels.REL_REPOSITORY_QUEUE,
>>>    controller.getRepositoryNode(),null
>>> );
>>> List<Long>  ids = new ArrayList<Long>();
>>> try {
>>>    for (Relationship hit : hits) {
>>>      ids.add(
>>>        hit.getEndNode().getId()
>>>      );
>>>    }
>>> } finally {
>>>    hits.close();
>>> }
>>> Collections.sort(ids);
>>> for (int i = offset; i<  Math.min(offset + buffersize,ids.size()); i++) {
>>>    list.add(
>>>      this.graph.getNodeById(
>>>        ids.get(i)
>>>      )
>>>    );
>>> }
>>> </pre>
>>>
>>> now my question. how can i efficiently get such a result list sorted for
>>> some node property other than id. and question number two: how would a
>>> cypher statement look like if it supported relationship-indices. maybe
>>>
>>> <pre>
>>> START x = (1)
>>> MATCH (x)-[r:(MyRelationIndex,type,MyRelationType)]->(y)
>>> RETURN r,y
>>> ORDER BY y.somePropertyOtherThanId
>>> </pre>
>>>
>>> similar to nodeIndexLookups, where i give the name of the relationship
>>> index to use, key and value for the relationship, start and end nodes
>>> are given by (x) and (y) in this case. i'd like that feature very much
>>> and if i knew how i'd probably even help to get on with it but anyway i
>>> can be patient.
>>>
>>>
>>> kindly, st.p.
>>> _______________________________________________
>>> Neo4j mailing list
>>> User@lists.neo4j.org
>>> https://lists.neo4j.org/mailman/listinfo/user
>>>
>>
>>
> _______________________________________________
> Neo4j mailing list
> User@lists.neo4j.org
> https://lists.neo4j.org/mailman/listinfo/user
>

_______________________________________________
Neo4j mailing list
User@lists.neo4j.org
https://lists.neo4j.org/mailman/listinfo/user

Reply via email to