[Neo] Neo4j + REST + .NET anyone?
Hi everyone! With the REST API approaching a usable state it would be great to get some clients written for it. Since I'll be presenting Neo4j at a .Net conference next week ( http://mow2010.dk/all-abstracts/tobias-ivarsson.aspx ) it would be great if there was a .Net client available for me to show. An early prototype would be enough, but I neither have the time, nor the .Net skills to implement it. Since this list is full of talented developers I thought I'd ask for some help. To make things more interesting I'll throw in a Neo4j t-shirt as a reward for the first .Net Neo4j REST client library with an accompanying small demo application. For reference see the documentation of the Neo4j REST API: * http://components.neo4j.org/neo4j-rest/ * http://wiki.neo4j.org/content/Getting_Started_REST WFC might be a good foundation to build the client library on: * http://damianm.com/tech/building-a-rest-client-with-wcf/ Happy hacking! -- Tobias Ivarsson tobias.ivars...@neotechnology.com Hacker, Neo Technology www.neotechnology.com Cellphone: +46 706 534857 ___ Neo mailing list User@lists.neo4j.org https://lists.neo4j.org/mailman/listinfo/user
Re: [Neo] Neo4j + REST + .NET anyone?
Hi, Tobias. It could be a fairly challenging task to do a general purpose .NET client using WCF, largely due to the flexibility of the return types (schema-less and type-less) from the REST API and some challenges that the DataContractJsonSerializer has in these scenarios. I think ultimately there's going to be a need for some type of metamodel built in so that inbound and outbound requests can properly map in and out of .NET domain models, but that's probably a bigger effort. There may be some other general purpose .NET client JSON parsers that would be easier to work with and more flexible (e.g. the JSON.NET project). One suggestion might be to add a DELETE method symmetric with the various get relationships on node methods. For example, DELETE /node/XXX/relationships/all would delete all relationships for node XXX. This helps make deletion of a node a simpler and more atomic operation. Also, I think the documentation in the Wiki for get relationships on node is incorrect since it shows a collection of nodes being returned. Lastly, I think it would be very valuable if the relationship type was returned from the REST API whenever a relationship or collection of relationships is returned. Along a related topic, has anyone started a .NET port of Neo4J yet (Neo4Net)? Cheers, Rick -Original Message- From: user-boun...@lists.neo4j.org [mailto:user-boun...@lists.neo4j.org] On Behalf Of Tobias Ivarsson Sent: Wednesday, April 07, 2010 10:37 AM To: Neo user discussions Subject: [Neo] Neo4j + REST + .NET anyone? Hi everyone! With the REST API approaching a usable state it would be great to get some clients written for it. Since I'll be presenting Neo4j at a .Net conference next week ( http://mow2010.dk/all-abstracts/tobias-ivarsson.aspx ) it would be great if there was a .Net client available for me to show. An early prototype would be enough, but I neither have the time, nor the .Net skills to implement it. Since this list is full of talented developers I thought I'd ask for some help. To make things more interesting I'll throw in a Neo4j t-shirt as a reward for the first .Net Neo4j REST client library with an accompanying small demo application. For reference see the documentation of the Neo4j REST API: * http://components.neo4j.org/neo4j-rest/ * http://wiki.neo4j.org/content/Getting_Started_REST WFC might be a good foundation to build the client library on: * http://damianm.com/tech/building-a-rest-client-with-wcf/ Happy hacking! -- Tobias Ivarsson tobias.ivars...@neotechnology.com Hacker, Neo Technology www.neotechnology.com Cellphone: +46 706 534857 ___ Neo mailing list User@lists.neo4j.org https://lists.neo4j.org/mailman/listinfo/user ___ Neo mailing list User@lists.neo4j.org https://lists.neo4j.org/mailman/listinfo/user
Re: [Neo] neo4j on .NET
Johan, Thank you for the nice news (and sorry for the late response: I've been on holidays and when came back I found loads of stuff to accomplish): I will dig out soon and come back to you... Cheers. Antonello On Mon, Jun 8, 2009 at 1:48 PM, Johan Svenssonjo...@neotechnology.com wrote: Antonello, Just thought I'd mention that trunk now has support for non memory mapped buffers. When starting Neo4j just pass in: use_memory_mapped_buffers=false as a parameter to the public EmbeddedNeo( String storeDir, MapString,String params ) constructor. The code of plain buffer/direct buffer ports of previously memory mapped ones are: org.neo4j.impl.nioneo.store.PlainPersistenceWindow org.neo4j.impl.transaction.xaframework.DirectMappedLogBuffer Regards, Johan On Tue, May 5, 2009 at 8:22 PM, Johan Svensson jo...@neotechnology.com wrote: Next release of Neo4j (b9) will have an option not to use memory mapped buffers but instead either use direct buffers or normal Java buffers. A .NET port could replace the org.neo4j.impl.nioneo.store.MappedPersistenceWindow with a different implementation that does not use the MappedByteBuffer (b9 will soon have such an implementation). In the transaction package any usage of MappedByteBuffer can be replaced with a direct or normal buffer also (they all just append data to some file). Hopefully I will get my test code of the new persistence windows into trunk soon. Once that is done a .NET port could make use of that and replace all other usages of memory mapped I/O with normal buffers. Regards, Johan On Sun, May 3, 2009 at 10:03 PM, Antonello Provenzano antone...@deveel.com wrote: I dug a bit the NIO package and the use done in neo4j: unfortunately there's not counter part for it on .NET nor the possibility to recreate [easily] classes to support it. In fact, you make a wide and important use of MappedByteBuffer on files: although implement the logics of a ByteBuffer class is not difficult (in .NET schema is the association of two classes: MemoryStream and BinaryWriter/BinaryReader), the behavior of MappedByteBuffer appears to be more complex, since access to portion of data in file which access must be coordinated with the memory, and this is not a simple issue. As of Java implementation, this is done natively and it's a complex operation to replicate the same functionality. Once this is solved, I see no further [major] obstacles to the port: avoiding the integration with the System.Transactions mechanism, the base of neo4j port would work in its core functionalities. Cheers. Antonello ___ Neo mailing list User@lists.neo4j.org https://lists.neo4j.org/mailman/listinfo/user ___ Neo mailing list User@lists.neo4j.org https://lists.neo4j.org/mailman/listinfo/user
Re: [Neo] neo4j on .NET
Johan, I checked out the latest sources from the SVN server of Neo and I haven't found the entry point you told me about (EmbeddedNeo constructor with use_memory_mapped_buffers parameter): can you clarify me if this can be found in some branch of the project or if isn't yet committed? Thank you! Antonello On Thu, Jul 2, 2009 at 3:09 PM, Antonello Provenzanoantone...@deveel.com wrote: Johan, Thank you for the nice news (and sorry for the late response: I've been on holidays and when came back I found loads of stuff to accomplish): I will dig out soon and come back to you... Cheers. Antonello On Mon, Jun 8, 2009 at 1:48 PM, Johan Svenssonjo...@neotechnology.com wrote: Antonello, Just thought I'd mention that trunk now has support for non memory mapped buffers. When starting Neo4j just pass in: use_memory_mapped_buffers=false as a parameter to the public EmbeddedNeo( String storeDir, MapString,String params ) constructor. The code of plain buffer/direct buffer ports of previously memory mapped ones are: org.neo4j.impl.nioneo.store.PlainPersistenceWindow org.neo4j.impl.transaction.xaframework.DirectMappedLogBuffer Regards, Johan On Tue, May 5, 2009 at 8:22 PM, Johan Svensson jo...@neotechnology.com wrote: Next release of Neo4j (b9) will have an option not to use memory mapped buffers but instead either use direct buffers or normal Java buffers. A .NET port could replace the org.neo4j.impl.nioneo.store.MappedPersistenceWindow with a different implementation that does not use the MappedByteBuffer (b9 will soon have such an implementation). In the transaction package any usage of MappedByteBuffer can be replaced with a direct or normal buffer also (they all just append data to some file). Hopefully I will get my test code of the new persistence windows into trunk soon. Once that is done a .NET port could make use of that and replace all other usages of memory mapped I/O with normal buffers. Regards, Johan On Sun, May 3, 2009 at 10:03 PM, Antonello Provenzano antone...@deveel.com wrote: I dug a bit the NIO package and the use done in neo4j: unfortunately there's not counter part for it on .NET nor the possibility to recreate [easily] classes to support it. In fact, you make a wide and important use of MappedByteBuffer on files: although implement the logics of a ByteBuffer class is not difficult (in .NET schema is the association of two classes: MemoryStream and BinaryWriter/BinaryReader), the behavior of MappedByteBuffer appears to be more complex, since access to portion of data in file which access must be coordinated with the memory, and this is not a simple issue. As of Java implementation, this is done natively and it's a complex operation to replicate the same functionality. Once this is solved, I see no further [major] obstacles to the port: avoiding the integration with the System.Transactions mechanism, the base of neo4j port would work in its core functionalities. Cheers. Antonello ___ Neo mailing list User@lists.neo4j.org https://lists.neo4j.org/mailman/listinfo/user ___ Neo mailing list User@lists.neo4j.org https://lists.neo4j.org/mailman/listinfo/user
Re: [Neo] neo4j on .NET
i dnt knw whether its related to the topic or not but am working on creating restful web service using jersey and then planning to implement and consume these service through .NET WCF.(WSE seems good option to me) or using silverlight's webservice support. please let me know what you guys think about this approach. suggestions are more then welcome. Thanks Ajay On Thu, Jul 2, 2009 at 8:54 PM, Antonello Provenzano antone...@deveel.comwrote: Johan, I checked out the latest sources from the SVN server of Neo and I haven't found the entry point you told me about (EmbeddedNeo constructor with use_memory_mapped_buffers parameter): can you clarify me if this can be found in some branch of the project or if isn't yet committed? Thank you! Antonello On Thu, Jul 2, 2009 at 3:09 PM, Antonello Provenzanoantone...@deveel.com wrote: Johan, Thank you for the nice news (and sorry for the late response: I've been on holidays and when came back I found loads of stuff to accomplish): I will dig out soon and come back to you... Cheers. Antonello On Mon, Jun 8, 2009 at 1:48 PM, Johan Svenssonjo...@neotechnology.com wrote: Antonello, Just thought I'd mention that trunk now has support for non memory mapped buffers. When starting Neo4j just pass in: use_memory_mapped_buffers=false as a parameter to the public EmbeddedNeo( String storeDir, MapString,String params ) constructor. The code of plain buffer/direct buffer ports of previously memory mapped ones are: org.neo4j.impl.nioneo.store.PlainPersistenceWindow org.neo4j.impl.transaction.xaframework.DirectMappedLogBuffer Regards, Johan On Tue, May 5, 2009 at 8:22 PM, Johan Svensson jo...@neotechnology.com wrote: Next release of Neo4j (b9) will have an option not to use memory mapped buffers but instead either use direct buffers or normal Java buffers. A .NET port could replace the org.neo4j.impl.nioneo.store.MappedPersistenceWindow with a different implementation that does not use the MappedByteBuffer (b9 will soon have such an implementation). In the transaction package any usage of MappedByteBuffer can be replaced with a direct or normal buffer also (they all just append data to some file). Hopefully I will get my test code of the new persistence windows into trunk soon. Once that is done a .NET port could make use of that and replace all other usages of memory mapped I/O with normal buffers. Regards, Johan On Sun, May 3, 2009 at 10:03 PM, Antonello Provenzano antone...@deveel.com wrote: I dug a bit the NIO package and the use done in neo4j: unfortunately there's not counter part for it on .NET nor the possibility to recreate [easily] classes to support it. In fact, you make a wide and important use of MappedByteBuffer on files: although implement the logics of a ByteBuffer class is not difficult (in .NET schema is the association of two classes: MemoryStream and BinaryWriter/BinaryReader), the behavior of MappedByteBuffer appears to be more complex, since access to portion of data in file which access must be coordinated with the memory, and this is not a simple issue. As of Java implementation, this is done natively and it's a complex operation to replicate the same functionality. Once this is solved, I see no further [major] obstacles to the port: avoiding the integration with the System.Transactions mechanism, the base of neo4j port would work in its core functionalities. Cheers. Antonello ___ Neo mailing list User@lists.neo4j.org https://lists.neo4j.org/mailman/listinfo/user ___ Neo mailing list User@lists.neo4j.org https://lists.neo4j.org/mailman/listinfo/user -- Ajay Sharma ___ Neo mailing list User@lists.neo4j.org https://lists.neo4j.org/mailman/listinfo/user
Re: [Neo] neo4j on .NET
Antonello, Pass it in as a key/value pair in the constructor that takes a configuration map: MapString,String params = new HashMapString,String(); params.put( use_memory_mapped_buffers, false ); NeoService neo = new EmbeddedNeo( neo-db, params ); Hope that helps. Regards, -Johan On Thu, Jul 2, 2009 at 5:24 PM, Antonello Provenzanoantone...@deveel.com wrote: Johan, I checked out the latest sources from the SVN server of Neo and I haven't found the entry point you told me about (EmbeddedNeo constructor with use_memory_mapped_buffers parameter): can you clarify me if this can be found in some branch of the project or if isn't yet committed? Thank you! Antonello On Thu, Jul 2, 2009 at 3:09 PM, Antonello Provenzanoantone...@deveel.com wrote: Johan, Thank you for the nice news (and sorry for the late response: I've been on holidays and when came back I found loads of stuff to accomplish): I will dig out soon and come back to you... Cheers. Antonello On Mon, Jun 8, 2009 at 1:48 PM, Johan Svenssonjo...@neotechnology.com wrote: Antonello, Just thought I'd mention that trunk now has support for non memory mapped buffers. When starting Neo4j just pass in: use_memory_mapped_buffers=false as a parameter to the public EmbeddedNeo( String storeDir, MapString,String params ) constructor. The code of plain buffer/direct buffer ports of previously memory mapped ones are: org.neo4j.impl.nioneo.store.PlainPersistenceWindow org.neo4j.impl.transaction.xaframework.DirectMappedLogBuffer Regards, Johan ___ Neo mailing list User@lists.neo4j.org https://lists.neo4j.org/mailman/listinfo/user
Re: [Neo] neo4j on .NET
Next release of Neo4j (b9) will have an option not to use memory mapped buffers but instead either use direct buffers or normal Java buffers. A .NET port could replace the org.neo4j.impl.nioneo.store.MappedPersistenceWindow with a different implementation that does not use the MappedByteBuffer (b9 will soon have such an implementation). In the transaction package any usage of MappedByteBuffer can be replaced with a direct or normal buffer also (they all just append data to some file). Hopefully I will get my test code of the new persistence windows into trunk soon. Once that is done a .NET port could make use of that and replace all other usages of memory mapped I/O with normal buffers. Regards, Johan On Sun, May 3, 2009 at 10:03 PM, Antonello Provenzano antone...@deveel.com wrote: I dug a bit the NIO package and the use done in neo4j: unfortunately there's not counter part for it on .NET nor the possibility to recreate [easily] classes to support it. In fact, you make a wide and important use of MappedByteBuffer on files: although implement the logics of a ByteBuffer class is not difficult (in .NET schema is the association of two classes: MemoryStream and BinaryWriter/BinaryReader), the behavior of MappedByteBuffer appears to be more complex, since access to portion of data in file which access must be coordinated with the memory, and this is not a simple issue. As of Java implementation, this is done natively and it's a complex operation to replicate the same functionality. Once this is solved, I see no further [major] obstacles to the port: avoiding the integration with the System.Transactions mechanism, the base of neo4j port would work in its core functionalities. Cheers. Antonello On Sun, May 3, 2009 at 4:51 PM, Johan Svensson jo...@neotechnology.com wrote: See my comments inline: On Sun, May 3, 2009 at 4:05 PM, Antonello Provenzano antone...@deveel.com wrote: Johan, I see. My knowledge of NIO is pretty limited indeed: since you're telling me it's re-designable with traditional java.io implementations, I see no particular issues on that side (also because, as you described some of the core functionalities, many features are already present in System.IO). In fact, what i did know was that NIO was used to stream remotely, opening communication channels between the local JVM and the remote endpoint (which could have been another running application in the same JVM). Yes, but we only use the native I/O part for files. Simply put, we want to avoid the extra copy of buffers that takes place from outside jvm memory to jvm buffers. NIO allows us to allocation direct buffers (that are allocated and managed outside the normal java heap). I also like the design of the nio package with channels and it is good that you can use the same interfaces to shuffle data over the network but Neo does not use those features (yet). Coming back to Transactions: it's true that JTA is just a set of specifications abstracted by the interfaces provided (which are easily convertible into .NET with a custom JTA packaging), but it's also true that .NET provides a framework for handling application transactions in the same fashion as JTA. In fact, when a developer instantiate a TransactionScope class, opens a transactional context for th execution of the calls withing that instance: to support this the JTA support present in neo4j should be adapted to the specifications provided by System.Transactions, which don't support XA nor 2PC (heavily used by neo4j). It should be possible to port Neo4j's transaction handling to support .NET's way of handling transactions. Neo will only make use of 2PC if there are multiple resources participating in the transaction. If you only use Neo and nothing else all commits will be optimized one phase commits. How would .NET handle a transaction that would like to modify something in two different databases in the same transactional context? That is what we use the two phase commit protocol for but if you only use Neo4j there is only one resources enlisted in the transaction so then it is not needed. It's true that it would be possible to create a custom transaction namespace within the ported neo4j, but this would change the behavior of the application: I don't know for sure, but JTA interacts with underlying systems for the management of transactions, as System.Transaction does; having a custom transaction mechanism would bypass all this. Yes, also it might be possible to just write some glue code between the .NET TransactionScope and the NeoService.beginTx() org.neo4j.api.core.Transaction classes. If all you need is single resource, begin,commit and rollback it would be much easier to integrate there and just do a straightforward port of the transaction package. Regards, Johan Cheers. Antonello ___ Neo mailing list User@lists.neo4j.org
Re: [Neo] neo4j on .NET
On Wed, May 6, 2009 at 02:05, Antonello Provenzano antone...@deveel.com wrote: I will try to elaborate a plan of porting as soon as it will be possible, coming back to you if i will find anything that will be an obstacle to it. In the meanwhile, I thought that the name neo4n would be appropriate for the project, being the j in the name referred to java. +1 Great initiative. Cheers, -- Emil Eifrém, CEO [e...@neotechnology.com] Neo Technology, www.neotechnology.com Cell: +46 733 462 271 | US: 206 403 8808 http://twitter.com/emileifrem ___ Neo mailing list User@lists.neo4j.org https://lists.neo4j.org/mailman/listinfo/user
Re: [Neo] neo4j on .NET
Hi! Have you tried using IKVM.NET? http://www.ikvm.net/ /anders Antonello Provenzano skrev: Emil, I'm a good expert on .NET architecture and technology, having contributed for years to the development of Mono and being a recognized developer and architect in this domain. Last week I tried to implement a port version of neo4j for .NET, applying the same concepts you implemented, not always plain porting the code: Java and C# themselves are pretty different seen from inside, and when you put in the middle also some architectural issues like transactions and such (eg. the NIO extension), the things become much less straight-forward. Although at the beginning my plan was to port in short time neo4j to .NET, once I analyzed the full source code I've been aware of the impossibility to accomplish this goal in small time: in fact, I decided to start the implemenation of a brand new project based on the concepts, rather than the actual code, of neo4j. This, as you can guess, requires additional work for the architectural design, prototyping and implementation, plus testing. In the short-medium term then, the best way will be to use a REST solution, as you suggested (but I've already considered, in case of not existence of native .NET solutions), which is not optimal by the way, although viable for the bootstrap of the project. I hope we will keep in touch anyway, in case i would need your and Neo's team assistance during the implementation of the .NET solution. Cheers! Antonello On Sun, May 3, 2009 at 4:11 AM, Emil Eifrem e...@neotechnology.com wrote: On Sun, May 3, 2009 at 03:55, Antonello Provenzano antone...@deveel.com wrote: I've found that neo4j would be perfect for my scope: unfortunately, it is purely written in Java code and it's not portable to .NET, because of the massive differences between the two architectures. Can you tell me if is it there any language binding or any port of neo4j for .NET/Mono? Hi Antonello, There's no port and no language binding at the time. I agree with you that porting Neo4j to .NET would probably be require a substantial investment, although I'm certainly no expert at .NET. As for bindings, I don't know how hard that would be. Neo4j currently has bindings for a number of languages (Python, Jython, Ruby, Clojure) and sometimes they've been fairly easy to roll. The conceptual impedance between Java and C# is certainly close to zero, so maybe adding .NET bindings is not that hard. You're certainly welcome to give it a shot! Another thought: Would it work if you implemented your graph algos in Java using Neo4j, then wrapped them in a thin REST layer and used that as a backend to the rest of your app written in .NET? Cheers, -- Emil Eifrém, CEO [e...@neotechnology.com] Neo Technology, www.neotechnology.com Cell: +46 733 462 271 | US: 206 403 8808 http://twitter.com/emileifrem ___ Neo mailing list User@lists.neo4j.org https://lists.neo4j.org/mailman/listinfo/user ___ Neo mailing list User@lists.neo4j.org https://lists.neo4j.org/mailman/listinfo/user -- Anders Nawroth [and...@neotechnology.com] GTalk, Skype: anders.nawroth Phone: +46 737 894 163 http://twitter.com/nawroth http://blog.nawroth.com/ ___ Neo mailing list User@lists.neo4j.org https://lists.neo4j.org/mailman/listinfo/user
Re: [Neo] neo4j on .NET
Anders, IKVM doesn't support the javax.transactions package. In fact, the main difference pointed out by neo4j between java and .NET is the lack of support for X/Open XA resource management: this is possible only by calling an interop OLEDB component, which is non-native .NET, which should be implemented in C++ and deployed to the host machine separately. Naturally, OLE development is forbidden in Linux machines, which makes things tougher. While under .NET framework (since the 2.0 specifications there's the inclusion of System.Transactions) it is provided a mechanism for transactions, architecturally different from the X/Open specifications (implemented with quite fidelity by javax.transactions), it is not provided a mechanism to handle MTS or two-phase commits. Since in neo4j one of the main aspects it's the XAResource implementation for persisting and retrieving data, the port is also conceptually difficult. Cheers. Antonello On Sun, May 3, 2009 at 9:59 AM, Anders Nawroth and...@neotechnology.com wrote: Hi! Have you tried using IKVM.NET? http://www.ikvm.net/ /anders Antonello Provenzano skrev: Emil, I'm a good expert on .NET architecture and technology, having contributed for years to the development of Mono and being a recognized developer and architect in this domain. Last week I tried to implement a port version of neo4j for .NET, applying the same concepts you implemented, not always plain porting the code: Java and C# themselves are pretty different seen from inside, and when you put in the middle also some architectural issues like transactions and such (eg. the NIO extension), the things become much less straight-forward. Although at the beginning my plan was to port in short time neo4j to .NET, once I analyzed the full source code I've been aware of the impossibility to accomplish this goal in small time: in fact, I decided to start the implemenation of a brand new project based on the concepts, rather than the actual code, of neo4j. This, as you can guess, requires additional work for the architectural design, prototyping and implementation, plus testing. In the short-medium term then, the best way will be to use a REST solution, as you suggested (but I've already considered, in case of not existence of native .NET solutions), which is not optimal by the way, although viable for the bootstrap of the project. I hope we will keep in touch anyway, in case i would need your and Neo's team assistance during the implementation of the .NET solution. Cheers! Antonello On Sun, May 3, 2009 at 4:11 AM, Emil Eifrem e...@neotechnology.com wrote: On Sun, May 3, 2009 at 03:55, Antonello Provenzano antone...@deveel.com wrote: I've found that neo4j would be perfect for my scope: unfortunately, it is purely written in Java code and it's not portable to .NET, because of the massive differences between the two architectures. Can you tell me if is it there any language binding or any port of neo4j for .NET/Mono? Hi Antonello, There's no port and no language binding at the time. I agree with you that porting Neo4j to .NET would probably be require a substantial investment, although I'm certainly no expert at .NET. As for bindings, I don't know how hard that would be. Neo4j currently has bindings for a number of languages (Python, Jython, Ruby, Clojure) and sometimes they've been fairly easy to roll. The conceptual impedance between Java and C# is certainly close to zero, so maybe adding .NET bindings is not that hard. You're certainly welcome to give it a shot! Another thought: Would it work if you implemented your graph algos in Java using Neo4j, then wrapped them in a thin REST layer and used that as a backend to the rest of your app written in .NET? Cheers, -- Emil Eifrém, CEO [e...@neotechnology.com] Neo Technology, www.neotechnology.com Cell: +46 733 462 271 | US: 206 403 8808 http://twitter.com/emileifrem ___ Neo mailing list User@lists.neo4j.org https://lists.neo4j.org/mailman/listinfo/user ___ Neo mailing list User@lists.neo4j.org https://lists.neo4j.org/mailman/listinfo/user -- Anders Nawroth [and...@neotechnology.com] GTalk, Skype: anders.nawroth Phone: +46 737 894 163 http://twitter.com/nawroth http://blog.nawroth.com/ ___ Neo mailing list User@lists.neo4j.org https://lists.neo4j.org/mailman/listinfo/user ___ Neo mailing list User@lists.neo4j.org https://lists.neo4j.org/mailman/listinfo/user
Re: [Neo] neo4j on .NET
Hi Antonello, Have a look at the neo-android component, dependency on javax.transaction has been dropped there (https://svn.neo4j.org/components/neo-android/trunk/) by just writing empty interfaces for all the javax.transaction stuff needed. javax.transaction / JTA and X/Open are just interfaces and specifications. There is no concrete implementation or magic performed by them so removing the dependency replacing with your own empty interfaces should work. See org.neo4j.impl.transaction and org.neo4j.impl.transaction.xaframework packages for the concrete implementation of JTA, XA resources, 2PC and so on. If it is possible to port for example the org.neo4j.impl.nioneo.store package to .NET there should be no problem to port the transaction and xaframework packages to .NET (they both use java.nio to manipulate files). Regards, -Johan On Sun, May 3, 2009 at 1:29 PM, Antonello Provenzano antone...@deveel.com wrote: Anders, IKVM doesn't support the javax.transactions package. In fact, the main difference pointed out by neo4j between java and .NET is the lack of support for X/Open XA resource management: this is possible only by calling an interop OLEDB component, which is non-native .NET, which should be implemented in C++ and deployed to the host machine separately. Naturally, OLE development is forbidden in Linux machines, which makes things tougher. While under .NET framework (since the 2.0 specifications there's the inclusion of System.Transactions) it is provided a mechanism for transactions, architecturally different from the X/Open specifications (implemented with quite fidelity by javax.transactions), it is not provided a mechanism to handle MTS or two-phase commits. Since in neo4j one of the main aspects it's the XAResource implementation for persisting and retrieving data, the port is also conceptually difficult. Cheers. Antonello On Sun, May 3, 2009 at 9:59 AM, Anders Nawroth and...@neotechnology.com wrote: Hi! Have you tried using IKVM.NET? http://www.ikvm.net/ /anders Antonello Provenzano skrev: Emil, I'm a good expert on .NET architecture and technology, having contributed for years to the development of Mono and being a recognized developer and architect in this domain. Last week I tried to implement a port version of neo4j for .NET, applying the same concepts you implemented, not always plain porting the code: Java and C# themselves are pretty different seen from inside, and when you put in the middle also some architectural issues like transactions and such (eg. the NIO extension), the things become much less straight-forward. Although at the beginning my plan was to port in short time neo4j to .NET, once I analyzed the full source code I've been aware of the impossibility to accomplish this goal in small time: in fact, I decided to start the implemenation of a brand new project based on the concepts, rather than the actual code, of neo4j. This, as you can guess, requires additional work for the architectural design, prototyping and implementation, plus testing. In the short-medium term then, the best way will be to use a REST solution, as you suggested (but I've already considered, in case of not existence of native .NET solutions), which is not optimal by the way, although viable for the bootstrap of the project. I hope we will keep in touch anyway, in case i would need your and Neo's team assistance during the implementation of the .NET solution. Cheers! Antonello On Sun, May 3, 2009 at 4:11 AM, Emil Eifrem e...@neotechnology.com wrote: On Sun, May 3, 2009 at 03:55, Antonello Provenzano antone...@deveel.com wrote: I've found that neo4j would be perfect for my scope: unfortunately, it is purely written in Java code and it's not portable to .NET, because of the massive differences between the two architectures. Can you tell me if is it there any language binding or any port of neo4j for .NET/Mono? Hi Antonello, There's no port and no language binding at the time. I agree with you that porting Neo4j to .NET would probably be require a substantial investment, although I'm certainly no expert at .NET. As for bindings, I don't know how hard that would be. Neo4j currently has bindings for a number of languages (Python, Jython, Ruby, Clojure) and sometimes they've been fairly easy to roll. The conceptual impedance between Java and C# is certainly close to zero, so maybe adding .NET bindings is not that hard. You're certainly welcome to give it a shot! Another thought: Would it work if you implemented your graph algos in Java using Neo4j, then wrapped them in a thin REST layer and used that as a backend to the rest of your app written in .NET? Cheers, -- Emil Eifrém, CEO [e...@neotechnology.com] Neo Technology, www.neotechnology.com Cell: +46 733 462 271 | US: 206 403 8808 http://twitter.com/emileifrem ___ Neo mailing list User@lists.neo4j.org
Re: [Neo] neo4j on .NET
Johan, I see. My knowledge of NIO is pretty limited indeed: since you're telling me it's re-designable with traditional java.io implementations, I see no particular issues on that side (also because, as you described some of the core functionalities, many features are already present in System.IO). In fact, what i did know was that NIO was used to stream remotely, opening communication channels between the local JVM and the remote endpoint (which could have been another running application in the same JVM). Coming back to Transactions: it's true that JTA is just a set of specifications abstracted by the interfaces provided (which are easily convertible into .NET with a custom JTA packaging), but it's also true that .NET provides a framework for handling application transactions in the same fashion as JTA. In fact, when a developer instantiate a TransactionScope class, opens a transactional context for th execution of the calls withing that instance: to support this the JTA support present in neo4j should be adapted to the specifications provided by System.Transactions, which don't support XA nor 2PC (heavily used by neo4j). It's true that it would be possible to create a custom transaction namespace within the ported neo4j, but this would change the behavior of the application: I don't know for sure, but JTA interacts with underlying systems for the management of transactions, as System.Transaction does; having a custom transaction mechanism would bypass all this. Cheers. Antonello On Sun, May 3, 2009 at 2:48 PM, Johan Svensson jo...@neotechnology.com wrote: Antonello, java.nio is used both for simplicity (code gets cleaner) and speed. The transaction packages and nioneo packages can be rewritten to use java.io but that would not perform very well. Basic file operations needed would be: o read/write into/from a buffer (byte array) from/to a file o change position in a file followed by reading/writing at/to that position o flush a file making sure all changes to that file are persisted o file truncation is nice to have too but not absolutely needed -Johan On Sun, May 3, 2009 at 2:26 PM, Antonello Provenzano antone...@deveel.com wrote: Johan, Thank you very much for the useful information and clarification: I will dig out and come back on this later, when I will have clearer view. Concerning the java.nio issue: in .NET there's not a counter part for the package. In fact, there's just the definition of the System.IO namespace, which provides implementations similar to java.io. The concepts before NIO are similar to the Remoting features of .NET, but the architecture is really different and not always is easily mappable. As said in my previous email, the architectural differences between the two technologies, specially after the latest developments (.NET, and C# in particular, were designed to be similar to Java and helping the transition of developers from one to another and reducing the learning curve, but latest technologies branched out of common aspects): *personally* I don't think that section would it be portable. Cheers. Antonello On Sun, May 3, 2009 at 2:10 PM, Johan Svensson jo...@neotechnology.com wrote: Hi Antonello, Have a look at the neo-android component, dependency on javax.transaction has been dropped there (https://svn.neo4j.org/components/neo-android/trunk/) by just writing empty interfaces for all the javax.transaction stuff needed. javax.transaction / JTA and X/Open are just interfaces and specifications. There is no concrete implementation or magic performed by them so removing the dependency replacing with your own empty interfaces should work. See org.neo4j.impl.transaction and org.neo4j.impl.transaction.xaframework packages for the concrete implementation of JTA, XA resources, 2PC and so on. If it is possible to port for example the org.neo4j.impl.nioneo.store package to .NET there should be no problem to port the transaction and xaframework packages to .NET (they both use java.nio to manipulate files). Regards, -Johan ___ Neo mailing list User@lists.neo4j.org https://lists.neo4j.org/mailman/listinfo/user ___ Neo mailing list User@lists.neo4j.org https://lists.neo4j.org/mailman/listinfo/user
Re: [Neo] neo4j on .NET
I dug a bit the NIO package and the use done in neo4j: unfortunately there's not counter part for it on .NET nor the possibility to recreate [easily] classes to support it. In fact, you make a wide and important use of MappedByteBuffer on files: although implement the logics of a ByteBuffer class is not difficult (in .NET schema is the association of two classes: MemoryStream and BinaryWriter/BinaryReader), the behavior of MappedByteBuffer appears to be more complex, since access to portion of data in file which access must be coordinated with the memory, and this is not a simple issue. As of Java implementation, this is done natively and it's a complex operation to replicate the same functionality. Once this is solved, I see no further [major] obstacles to the port: avoiding the integration with the System.Transactions mechanism, the base of neo4j port would work in its core functionalities. Cheers. Antonello On Sun, May 3, 2009 at 4:51 PM, Johan Svensson jo...@neotechnology.com wrote: See my comments inline: On Sun, May 3, 2009 at 4:05 PM, Antonello Provenzano antone...@deveel.com wrote: Johan, I see. My knowledge of NIO is pretty limited indeed: since you're telling me it's re-designable with traditional java.io implementations, I see no particular issues on that side (also because, as you described some of the core functionalities, many features are already present in System.IO). In fact, what i did know was that NIO was used to stream remotely, opening communication channels between the local JVM and the remote endpoint (which could have been another running application in the same JVM). Yes, but we only use the native I/O part for files. Simply put, we want to avoid the extra copy of buffers that takes place from outside jvm memory to jvm buffers. NIO allows us to allocation direct buffers (that are allocated and managed outside the normal java heap). I also like the design of the nio package with channels and it is good that you can use the same interfaces to shuffle data over the network but Neo does not use those features (yet). Coming back to Transactions: it's true that JTA is just a set of specifications abstracted by the interfaces provided (which are easily convertible into .NET with a custom JTA packaging), but it's also true that .NET provides a framework for handling application transactions in the same fashion as JTA. In fact, when a developer instantiate a TransactionScope class, opens a transactional context for th execution of the calls withing that instance: to support this the JTA support present in neo4j should be adapted to the specifications provided by System.Transactions, which don't support XA nor 2PC (heavily used by neo4j). It should be possible to port Neo4j's transaction handling to support .NET's way of handling transactions. Neo will only make use of 2PC if there are multiple resources participating in the transaction. If you only use Neo and nothing else all commits will be optimized one phase commits. How would .NET handle a transaction that would like to modify something in two different databases in the same transactional context? That is what we use the two phase commit protocol for but if you only use Neo4j there is only one resources enlisted in the transaction so then it is not needed. It's true that it would be possible to create a custom transaction namespace within the ported neo4j, but this would change the behavior of the application: I don't know for sure, but JTA interacts with underlying systems for the management of transactions, as System.Transaction does; having a custom transaction mechanism would bypass all this. Yes, also it might be possible to just write some glue code between the .NET TransactionScope and the NeoService.beginTx() org.neo4j.api.core.Transaction classes. If all you need is single resource, begin,commit and rollback it would be much easier to integrate there and just do a straightforward port of the transaction package. Regards, Johan Cheers. Antonello On Sun, May 3, 2009 at 2:48 PM, Johan Svensson jo...@neotechnology.com wrote: Antonello, java.nio is used both for simplicity (code gets cleaner) and speed. The transaction packages and nioneo packages can be rewritten to use java.io but that would not perform very well. Basic file operations needed would be: o read/write into/from a buffer (byte array) from/to a file o change position in a file followed by reading/writing at/to that position o flush a file making sure all changes to that file are persisted o file truncation is nice to have too but not absolutely needed -Johan On Sun, May 3, 2009 at 2:26 PM, Antonello Provenzano antone...@deveel.com wrote: Johan, Thank you very much for the useful information and clarification: I will dig out and come back on this later, when I will have clearer view. Concerning the java.nio issue: in .NET there's not a counter part for the package.
[Neo] neo4j on .NET
Hi all, I've been designing an application, based on .NET/Mono framework, which should make an heavy use of the shortest-path in a graph theories and I would like to use a native solution to traverse the nodes of the graph, instead of implementing surrogate solutions which would be hardly maintainable and would massively affect performances. I've found that neo4j would be perfect for my scope: unfortunately, it is purely written in Java code and it's not portable to .NET, because of the massive differences between the two architectures. Can you tell me if is it there any language binding or any port of neo4j for .NET/Mono? Thank you all Antonello ___ Neo mailing list User@lists.neo4j.org https://lists.neo4j.org/mailman/listinfo/user
Re: [Neo] neo4j on .NET
On Sun, May 3, 2009 at 03:55, Antonello Provenzano antone...@deveel.com wrote: I've found that neo4j would be perfect for my scope: unfortunately, it is purely written in Java code and it's not portable to .NET, because of the massive differences between the two architectures. Can you tell me if is it there any language binding or any port of neo4j for .NET/Mono? Hi Antonello, There's no port and no language binding at the time. I agree with you that porting Neo4j to .NET would probably be require a substantial investment, although I'm certainly no expert at .NET. As for bindings, I don't know how hard that would be. Neo4j currently has bindings for a number of languages (Python, Jython, Ruby, Clojure) and sometimes they've been fairly easy to roll. The conceptual impedance between Java and C# is certainly close to zero, so maybe adding .NET bindings is not that hard. You're certainly welcome to give it a shot! Another thought: Would it work if you implemented your graph algos in Java using Neo4j, then wrapped them in a thin REST layer and used that as a backend to the rest of your app written in .NET? Cheers, -- Emil Eifrém, CEO [e...@neotechnology.com] Neo Technology, www.neotechnology.com Cell: +46 733 462 271 | US: 206 403 8808 http://twitter.com/emileifrem ___ Neo mailing list User@lists.neo4j.org https://lists.neo4j.org/mailman/listinfo/user
Re: [Neo] neo4j on .NET
Emil, I'm a good expert on .NET architecture and technology, having contributed for years to the development of Mono and being a recognized developer and architect in this domain. Last week I tried to implement a port version of neo4j for .NET, applying the same concepts you implemented, not always plain porting the code: Java and C# themselves are pretty different seen from inside, and when you put in the middle also some architectural issues like transactions and such (eg. the NIO extension), the things become much less straight-forward. Although at the beginning my plan was to port in short time neo4j to .NET, once I analyzed the full source code I've been aware of the impossibility to accomplish this goal in small time: in fact, I decided to start the implemenation of a brand new project based on the concepts, rather than the actual code, of neo4j. This, as you can guess, requires additional work for the architectural design, prototyping and implementation, plus testing. In the short-medium term then, the best way will be to use a REST solution, as you suggested (but I've already considered, in case of not existence of native .NET solutions), which is not optimal by the way, although viable for the bootstrap of the project. I hope we will keep in touch anyway, in case i would need your and Neo's team assistance during the implementation of the .NET solution. Cheers! Antonello On Sun, May 3, 2009 at 4:11 AM, Emil Eifrem e...@neotechnology.com wrote: On Sun, May 3, 2009 at 03:55, Antonello Provenzano antone...@deveel.com wrote: I've found that neo4j would be perfect for my scope: unfortunately, it is purely written in Java code and it's not portable to .NET, because of the massive differences between the two architectures. Can you tell me if is it there any language binding or any port of neo4j for .NET/Mono? Hi Antonello, There's no port and no language binding at the time. I agree with you that porting Neo4j to .NET would probably be require a substantial investment, although I'm certainly no expert at .NET. As for bindings, I don't know how hard that would be. Neo4j currently has bindings for a number of languages (Python, Jython, Ruby, Clojure) and sometimes they've been fairly easy to roll. The conceptual impedance between Java and C# is certainly close to zero, so maybe adding .NET bindings is not that hard. You're certainly welcome to give it a shot! Another thought: Would it work if you implemented your graph algos in Java using Neo4j, then wrapped them in a thin REST layer and used that as a backend to the rest of your app written in .NET? Cheers, -- Emil Eifrém, CEO [e...@neotechnology.com] Neo Technology, www.neotechnology.com Cell: +46 733 462 271 | US: 206 403 8808 http://twitter.com/emileifrem ___ Neo mailing list User@lists.neo4j.org https://lists.neo4j.org/mailman/listinfo/user ___ Neo mailing list User@lists.neo4j.org https://lists.neo4j.org/mailman/listinfo/user
