Re: [Neo4j] Release 1.0.0.beta.22
Excellent - a truce :-) So, let's get something in place this week. We both want to see the spatial index (and I hope the composite index) get some more visibility, and we both want it to be as clear an intuitive as possible. On Sun, Nov 28, 2010 at 6:10 PM, Peter Neubauer peter.neuba...@neotechnology.com wrote: Yes, totally true. We should talkt ot Mattias on the option of having some Index suppoerted that is configured upfront and then simply has index.add(PropertyContainer). Totally with you there :) Cheers, /peter neubauer GTalk: neubauer.peter Skype peter.neubauer Phone +46 704 106975 LinkedIn http://www.linkedin.com/in/neubauer Twitter http://twitter.com/peterneubauer http://www.neo4j.org - Your high performance graph database. http://www.thoughtmade.com - Scandinavia's coolest Bring-a-Thing party. On Sun, Nov 28, 2010 at 6:08 PM, Craig Taverner cr...@amanzi.com wrote: It seems we are still talking about different things. My request for an index API is actually *simpler* than the existing standard in Neo4j. In fact the existing API is already fine for creating the index, finding the index, performing queries on the index, everything except one call, index.add(node,string,object). I would prefer index.add(node). So, in terms of API, if we want to discuss simplicity, it is the other way round. However, that is not the issue here. The main argument is all about the *purpose of the index*. The existing API is explicitly for indexing key/value pairs on PropertyContainers. While we could easily adapt this to indexing other concepts, I have strong reservations about whether that is a *good thing(tm)* to do. IMHO it might be somewhat confusing to the user for the same API to be used for different concepts. So, what are our options here? Take a look back at the method I mentioned above: index.add(node,string,object). This call exposes the fundamental difference, and that is that in the current implementation the name of the index really defines a unique implementation of something that can index key-value pairs, and then the key/value to index is specified on each and every add() call. This allows the same index to be used for different properties (keys) in a clean way. If we want to index more complex concepts, like geometry, or multiple linked properties, we could not, and should not, just add new versions of this call for those cases (like add(node,Geometry), or add(node,key1,obj1,key2,obj2,key3,obj3)). IMHO, more complex cases should be handled with a simpler API. Use index.add(node), and make the index instance specific to the particular complication being dealt with. The current API for creating, finding and querying can already handle all levels of complexity. It is only the add() method that is specific to single key-value pairs. This means we have two main options: - Produce an extension/modification to the existing API allowing for index.add(propertyContainer) and keep the current index creation/finding/querying API as is. This would work and the two methods add(node,string,object) and add(node) would be the hint to the user that these are two different types of index. I'm still uncomfortable with this, because I think the difference is too subtle, and likely to lead to confusion. - Have a second index API focusing on the add(node) use case. The second API should be clearly different in intention from the first, because in this case the properties to index are specified at index creation, not when adding to the index. This is a very key difference which I think should be visible to the developer, so they do not mix the two up. And this gets us back to the original point. You must have some reason for wanting to put other, non-key-value, indexes behind the existing key-value index API. As you can tell, so far I can only see problems with this idea, but I'm quite sure you can see advantages with it. Obviously these advantages need to be taken into account. In my opinion the goal should be to achieve maximum overall simplicity and clarity in using indexes of all types in Neo4j. On Sat, Nov 27, 2010 at 11:24 PM, Peter Neubauer peter.neuba...@neotechnology.com wrote: Mmh, as stated before, IMHO there can be different scenarios of usage of complex indexes. Of course there is a reason for GeoTools and GIS systems to have a more complicated API than a Lucene Text search index. GIS queries tend to be far more complex than text queries, especially when we want to combine them with other deep raversals through the graph. In that I agree with you Craig. However, I think there is a place for a simple API (with only simple support for features) that would satisfy a lot of users that are starting to explore the concept of multidimensional indexing and simple
Re: [Neo4j] Release 1.0.0.beta.22
Yes, actually it's not that bad of an idea :) You control which properties are going to be indexed with a configuration parameter up front and then you just hand the PropertyContainer to the index and it'll index those properties it was told to index, like: IndexNode index = db.index().forNodes(MapUtil.stringMap( provider, lucene, type, exact, keys_to_index, name,title ) ); ... index.add( node ); index.add( anotherNode ); You could still keep the add(entity,key,value) maybe for special cases? Or maybe that'd be confusing. 2010/11/28 Peter Neubauer peter.neuba...@neotechnology.com Yes, totally true. We should talkt ot Mattias on the option of having some Index suppoerted that is configured upfront and then simply has index.add(PropertyContainer). Totally with you there :) Cheers, /peter neubauer GTalk: neubauer.peter Skype peter.neubauer Phone +46 704 106975 LinkedIn http://www.linkedin.com/in/neubauer Twitter http://twitter.com/peterneubauer http://www.neo4j.org - Your high performance graph database. http://www.thoughtmade.com - Scandinavia's coolest Bring-a-Thing party. On Sun, Nov 28, 2010 at 6:08 PM, Craig Taverner cr...@amanzi.com wrote: It seems we are still talking about different things. My request for an index API is actually *simpler* than the existing standard in Neo4j. In fact the existing API is already fine for creating the index, finding the index, performing queries on the index, everything except one call, index.add(node,string,object). I would prefer index.add(node). So, in terms of API, if we want to discuss simplicity, it is the other way round. However, that is not the issue here. The main argument is all about the *purpose of the index*. The existing API is explicitly for indexing key/value pairs on PropertyContainers. While we could easily adapt this to indexing other concepts, I have strong reservations about whether that is a *good thing(tm)* to do. IMHO it might be somewhat confusing to the user for the same API to be used for different concepts. So, what are our options here? Take a look back at the method I mentioned above: index.add(node,string,object). This call exposes the fundamental difference, and that is that in the current implementation the name of the index really defines a unique implementation of something that can index key-value pairs, and then the key/value to index is specified on each and every add() call. This allows the same index to be used for different properties (keys) in a clean way. If we want to index more complex concepts, like geometry, or multiple linked properties, we could not, and should not, just add new versions of this call for those cases (like add(node,Geometry), or add(node,key1,obj1,key2,obj2,key3,obj3)). IMHO, more complex cases should be handled with a simpler API. Use index.add(node), and make the index instance specific to the particular complication being dealt with. The current API for creating, finding and querying can already handle all levels of complexity. It is only the add() method that is specific to single key-value pairs. This means we have two main options: - Produce an extension/modification to the existing API allowing for index.add(propertyContainer) and keep the current index creation/finding/querying API as is. This would work and the two methods add(node,string,object) and add(node) would be the hint to the user that these are two different types of index. I'm still uncomfortable with this, because I think the difference is too subtle, and likely to lead to confusion. - Have a second index API focusing on the add(node) use case. The second API should be clearly different in intention from the first, because in this case the properties to index are specified at index creation, not when adding to the index. This is a very key difference which I think should be visible to the developer, so they do not mix the two up. And this gets us back to the original point. You must have some reason for wanting to put other, non-key-value, indexes behind the existing key-value index API. As you can tell, so far I can only see problems with this idea, but I'm quite sure you can see advantages with it. Obviously these advantages need to be taken into account. In my opinion the goal should be to achieve maximum overall simplicity and clarity in using indexes of all types in Neo4j. On Sat, Nov 27, 2010 at 11:24 PM, Peter Neubauer peter.neuba...@neotechnology.com wrote: Mmh, as stated before, IMHO there can be different scenarios of usage of complex indexes. Of course there is a reason for GeoTools and GIS systems to have a more complicated API than a Lucene Text search index. GIS queries tend to be far more complex than text queries, especially when we want to combine them with
Re: [Neo4j] Release 1.0.0.beta.22
Yes, Upfront configured indexes IMHO are very useful, especially if we connect them with events later ... they probably fit a wide array of use cases. Cheers, /peter neubauer GTalk: neubauer.peter Skype peter.neubauer Phone +46 704 106975 LinkedIn http://www.linkedin.com/in/neubauer Twitter http://twitter.com/peterneubauer http://www.neo4j.org - Your high performance graph database. http://www.thoughtmade.com - Scandinavia's coolest Bring-a-Thing party. On Sun, Nov 28, 2010 at 9:28 PM, Mattias Persson matt...@neotechnology.com wrote: Yes, actually it's not that bad of an idea :) You control which properties are going to be indexed with a configuration parameter up front and then you just hand the PropertyContainer to the index and it'll index those properties it was told to index, like: IndexNode index = db.index().forNodes(MapUtil.stringMap( provider, lucene, type, exact, keys_to_index, name,title ) ); ... index.add( node ); index.add( anotherNode ); You could still keep the add(entity,key,value) maybe for special cases? Or maybe that'd be confusing. 2010/11/28 Peter Neubauer peter.neuba...@neotechnology.com Yes, totally true. We should talkt ot Mattias on the option of having some Index suppoerted that is configured upfront and then simply has index.add(PropertyContainer). Totally with you there :) Cheers, /peter neubauer GTalk: neubauer.peter Skype peter.neubauer Phone +46 704 106975 LinkedIn http://www.linkedin.com/in/neubauer Twitter http://twitter.com/peterneubauer http://www.neo4j.org - Your high performance graph database. http://www.thoughtmade.com - Scandinavia's coolest Bring-a-Thing party. On Sun, Nov 28, 2010 at 6:08 PM, Craig Taverner cr...@amanzi.com wrote: It seems we are still talking about different things. My request for an index API is actually *simpler* than the existing standard in Neo4j. In fact the existing API is already fine for creating the index, finding the index, performing queries on the index, everything except one call, index.add(node,string,object). I would prefer index.add(node). So, in terms of API, if we want to discuss simplicity, it is the other way round. However, that is not the issue here. The main argument is all about the *purpose of the index*. The existing API is explicitly for indexing key/value pairs on PropertyContainers. While we could easily adapt this to indexing other concepts, I have strong reservations about whether that is a *good thing(tm)* to do. IMHO it might be somewhat confusing to the user for the same API to be used for different concepts. So, what are our options here? Take a look back at the method I mentioned above: index.add(node,string,object). This call exposes the fundamental difference, and that is that in the current implementation the name of the index really defines a unique implementation of something that can index key-value pairs, and then the key/value to index is specified on each and every add() call. This allows the same index to be used for different properties (keys) in a clean way. If we want to index more complex concepts, like geometry, or multiple linked properties, we could not, and should not, just add new versions of this call for those cases (like add(node,Geometry), or add(node,key1,obj1,key2,obj2,key3,obj3)). IMHO, more complex cases should be handled with a simpler API. Use index.add(node), and make the index instance specific to the particular complication being dealt with. The current API for creating, finding and querying can already handle all levels of complexity. It is only the add() method that is specific to single key-value pairs. This means we have two main options: - Produce an extension/modification to the existing API allowing for index.add(propertyContainer) and keep the current index creation/finding/querying API as is. This would work and the two methods add(node,string,object) and add(node) would be the hint to the user that these are two different types of index. I'm still uncomfortable with this, because I think the difference is too subtle, and likely to lead to confusion. - Have a second index API focusing on the add(node) use case. The second API should be clearly different in intention from the first, because in this case the properties to index are specified at index creation, not when adding to the index. This is a very key difference which I think should be visible to the developer, so they do not mix the two up. And this gets us back to the original point. You must have some reason for wanting to put other, non-key-value, indexes behind the existing key-value index API. As you can tell, so far I can only see problems with this idea, but I'm quite sure you can see advantages with it. Obviously these
Re: [Neo4j] Release 1.0.0.beta.22
Yay! We're on a role here. However, I suspect that deprecating the index.add(node,string,object) will not be easy. The usage of that is somewhat different, and probably widespread. I think both styles will need to co-exist. The trick is to get them to co-exist without creating confusion. On Sun, Nov 28, 2010 at 10:34 PM, Peter Neubauer peter.neuba...@neotechnology.com wrote: Yes, Upfront configured indexes IMHO are very useful, especially if we connect them with events later ... they probably fit a wide array of use cases. Cheers, /peter neubauer GTalk: neubauer.peter Skype peter.neubauer Phone +46 704 106975 LinkedIn http://www.linkedin.com/in/neubauer Twitter http://twitter.com/peterneubauer http://www.neo4j.org - Your high performance graph database. http://www.thoughtmade.com - Scandinavia's coolest Bring-a-Thing party. On Sun, Nov 28, 2010 at 9:28 PM, Mattias Persson matt...@neotechnology.com wrote: Yes, actually it's not that bad of an idea :) You control which properties are going to be indexed with a configuration parameter up front and then you just hand the PropertyContainer to the index and it'll index those properties it was told to index, like: IndexNode index = db.index().forNodes(MapUtil.stringMap( provider, lucene, type, exact, keys_to_index, name,title ) ); ... index.add( node ); index.add( anotherNode ); You could still keep the add(entity,key,value) maybe for special cases? Or maybe that'd be confusing. 2010/11/28 Peter Neubauer peter.neuba...@neotechnology.com Yes, totally true. We should talkt ot Mattias on the option of having some Index suppoerted that is configured upfront and then simply has index.add(PropertyContainer). Totally with you there :) Cheers, /peter neubauer GTalk: neubauer.peter Skype peter.neubauer Phone +46 704 106975 LinkedIn http://www.linkedin.com/in/neubauer Twitter http://twitter.com/peterneubauer http://www.neo4j.org - Your high performance graph database. http://www.thoughtmade.com - Scandinavia's coolest Bring-a-Thing party. On Sun, Nov 28, 2010 at 6:08 PM, Craig Taverner cr...@amanzi.com wrote: It seems we are still talking about different things. My request for an index API is actually *simpler* than the existing standard in Neo4j. In fact the existing API is already fine for creating the index, finding the index, performing queries on the index, everything except one call, index.add(node,string,object). I would prefer index.add(node). So, in terms of API, if we want to discuss simplicity, it is the other way round. However, that is not the issue here. The main argument is all about the *purpose of the index*. The existing API is explicitly for indexing key/value pairs on PropertyContainers. While we could easily adapt this to indexing other concepts, I have strong reservations about whether that is a *good thing(tm)* to do. IMHO it might be somewhat confusing to the user for the same API to be used for different concepts. So, what are our options here? Take a look back at the method I mentioned above: index.add(node,string,object). This call exposes the fundamental difference, and that is that in the current implementation the name of the index really defines a unique implementation of something that can index key-value pairs, and then the key/value to index is specified on each and every add() call. This allows the same index to be used for different properties (keys) in a clean way. If we want to index more complex concepts, like geometry, or multiple linked properties, we could not, and should not, just add new versions of this call for those cases (like add(node,Geometry), or add(node,key1,obj1,key2,obj2,key3,obj3)). IMHO, more complex cases should be handled with a simpler API. Use index.add(node), and make the index instance specific to the particular complication being dealt with. The current API for creating, finding and querying can already handle all levels of complexity. It is only the add() method that is specific to single key-value pairs. This means we have two main options: - Produce an extension/modification to the existing API allowing for index.add(propertyContainer) and keep the current index creation/finding/querying API as is. This would work and the two methods add(node,string,object) and add(node) would be the hint to the user that these are two different types of index. I'm still uncomfortable with this, because I think the difference is too subtle, and likely to lead to confusion. - Have a second index API focusing on the add(node) use case. The second API should be clearly different in intention from the first, because in this case the
Re: [Neo4j] Release 1.0.0.beta.22
Any time you introduce an unnecessary transformation step (native types - XML/JSON - native types), you're introducing multiple types of overhead. Perhaps a more native/binary protocol would enable a better generic remote invocation layer (with multiple types of formats supported based on the requestor's preference). Also, the atomicity of the way many REST-ful API's are designed/optimized often makes it difficult/undesirable to maintain a 1:1 correlation with the Neo API. You might want to offer both a raw (ability to do TX stuff) and an atomic (implicit transactions) version. I suppose another consideration if doing very granular API calls remotely is connection and communications management (socket vs HTTP vs whatever) and the implications of this in an HA environment. I guess what I'm suggesting is that there probably is no single answer, and the most functional solution may require multiple ways of surfacing Neo's functionality to remote consumers. -Original Message- From: user-boun...@lists.neo4j.org [mailto:user-boun...@lists.neo4j.org] On Behalf Of Peter Neubauer Sent: Friday, November 26, 2010 2:04 AM To: neo4jrb; Neo4j user discussions Subject: Re: [Neo4j] Release 1.0.0.beta.22 Great stuff Andreas, we had a great evening in Barcelona yesterday, showing off the great work you, Ben and all the others are doing! Fantastic API and features! Craig and me are working on getting the Neo4j Spatial supported (at least the basic features) as a normal index provider in Neo4j. That would mean that you then in Neo4j.rb can directly ask not only text queries with Lucene but even spatial queries. Would be very cool to get that in, too :) Btw, what does everyone feel about REST vs. native protocols like RMI, Protobuffers, etc that can support a full Neo4j remote API for integration, with TX etc and would be optimized for driver development in other langs, minicing the Java core API capabilities very close? Any thoughts or preferences on one or the other? Does REST do a sufficiently good job for production use from other langs? What would you like to see in REST to get there - top 3 features? We are just trying to figure out the best way to expose and support the different Remote options ... Cheers, /peter neubauer GTalk: neubauer.peter Skype peter.neubauer Phone +46 704 106975 LinkedIn http://www.linkedin.com/in/neubauer Twitter http://twitter.com/peterneubauer http://www.neo4j.org - Your high performance graph database. http://www.thoughtmade.com - Scandinavia's coolest Bring-a-Thing party. On Thu, Nov 25, 2010 at 8:00 PM, Andreas Ronge andreas.ro...@gmail.com wrote: Hi I've just released 1.0.0.beta.22 The big news is that you can now use the rails console while the rails application is already running. I first tried to access neo4j remotely via RMI and DRb but there were to many problems doing that, so instead I simply create a read only neo4j db when needed. CHANGELOG * If a neo4j write instance is already running it will instead start a read only neo4j db instance. * Upgrade JARS to 1.2.M04 * Does not automatically start Neo4j when used in Rails. E.g. now you can type rails routes without the database starting. -- You received this message because you are subscribed to the Google Groups neo4jrb group. To post to this group, send email to neo4...@googlegroups.com. To unsubscribe from this group, send email to neo4jrb+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/neo4jrb?hl=en. ___ 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
Re: [Neo4j] Release 1.0.0.beta.22
On Fri, Nov 26, 2010 at 02:03, Peter Neubauer peter.neuba...@neotechnology.com wrote: Btw, what does everyone feel about REST vs. native protocols like RMI, Protobuffers, etc that can support a full Neo4j remote API for integration, with TX etc and would be optimized for driver development in other langs, minicing the Java core API capabilities very close? Any thoughts or preferences on one or the other? Does REST do a sufficiently good job for production use from other langs? What would you like to see in REST to get there - top 3 features? My 3 cents: - Sockets maybe? - Support for Dates, and not only dates after Linux Epoch. - Support for do traversal with the geospatial information. Using GeoJSON or WKT? -- Javier de la Rosa http://versae.es ___ Neo4j mailing list User@lists.neo4j.org https://lists.neo4j.org/mailman/listinfo/user
Re: [Neo4j] Release 1.0.0.beta.22
Thanks for the feedback! On the GoeSpatial side, I am trying to get the setup easier, so for normal stuff, you don't have to go through GeoTeools but can use the Neo4j Index setup, see https://github.com/neo4j/neo4j-spatial/blob/300f4d1d1fbb92d6252d5be6dc334250c9514bc7/src/test/java/org/neo4j/gis/spatial/IndexProviderTest.java#L51 after just including Neo4j-Spatial into your dependencies. This syntax might make it easier to expose things in Ruby, REST and others, too. WDYT? For the heavy query lifting and GIS stack integration, the GeoTools API is the way to go though ... Date support in Neo4j is a very interesting thing that I think needs a bit of thought. Thanks for pointing it out - would be a great lab-friday project :) Cheers, /peter neubauer GTalk: neubauer.peter Skype peter.neubauer Phone +46 704 106975 LinkedIn http://www.linkedin.com/in/neubauer Twitter http://twitter.com/peterneubauer http://www.neo4j.org - Your high performance graph database. http://www.thoughtmade.com - Scandinavia's coolest Bring-a-Thing party. On Fri, Nov 26, 2010 at 3:08 PM, Javier de la Rosa ver...@gmail.com wrote: On Fri, Nov 26, 2010 at 02:03, Peter Neubauer peter.neuba...@neotechnology.com wrote: Btw, what does everyone feel about REST vs. native protocols like RMI, Protobuffers, etc that can support a full Neo4j remote API for integration, with TX etc and would be optimized for driver development in other langs, minicing the Java core API capabilities very close? Any thoughts or preferences on one or the other? Does REST do a sufficiently good job for production use from other langs? What would you like to see in REST to get there - top 3 features? My 3 cents: - Sockets maybe? - Support for Dates, and not only dates after Linux Epoch. - Support for do traversal with the geospatial information. Using GeoJSON or WKT? -- Javier de la Rosa http://versae.es ___ 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
Re: [Neo4j] Release 1.0.0.beta.22
On Fri, Nov 26, 2010 at 10:54, Peter Neubauer peter.neuba...@neotechnology.com wrote: [...] This syntax might make it easier to expose things in Ruby, REST and others, too. WDYT? For the heavy query lifting and GIS stack integration, the GeoTools API is the way to go though ... Any mechanism that make possible to build traversals with geospatial information through the REST API would be great. So, in some moment in the future, will be possible do traversals with geodata?, I mean, build traversals in which I could asking the nodes using geospatial operations like near, is a point of, overlap with, to a distance less than, etc. Date support in Neo4j is a very interesting thing that I think needs a bit of thought. Thanks for pointing it out - would be a great lab-friday project :) Great! I would like to know some more about Java to help in a more useful way. Thank you. Cheers, /peter neubauer GTalk: neubauer.peter Skype peter.neubauer Phone +46 704 106975 LinkedIn http://www.linkedin.com/in/neubauer Twitter http://twitter.com/peterneubauer http://www.neo4j.org - Your high performance graph database. http://www.thoughtmade.com - Scandinavia's coolest Bring-a-Thing party. On Fri, Nov 26, 2010 at 3:08 PM, Javier de la Rosa ver...@gmail.com wrote: On Fri, Nov 26, 2010 at 02:03, Peter Neubauer peter.neuba...@neotechnology.com wrote: Btw, what does everyone feel about REST vs. native protocols like RMI, Protobuffers, etc that can support a full Neo4j remote API for integration, with TX etc and would be optimized for driver development in other langs, minicing the Java core API capabilities very close? Any thoughts or preferences on one or the other? Does REST do a sufficiently good job for production use from other langs? What would you like to see in REST to get there - top 3 features? My 3 cents: - Sockets maybe? - Support for Dates, and not only dates after Linux Epoch. - Support for do traversal with the geospatial information. Using GeoJSON or WKT? -- Javier de la Rosa http://versae.es ___ 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 -- Javier de la Rosa http://versae.es ___ Neo4j mailing list User@lists.neo4j.org https://lists.neo4j.org/mailman/listinfo/user
Re: [Neo4j] Release 1.0.0.beta.22
I must admit I am not happy with the index.add(node,key,value) API for spatial data. See the line in Peters code: index.add( n1, dummy, value ); Peter had to put dummy values in the call to 'work around' this requirement. In fact I'm not happy with this for my composite index either. For both cases (spatial and composite), you configure the properties to be indexed once for the index as a whole and then call index.add(node) for each node to index. This has many advantages: - The index can be optimised or specific to the combinations of properties configured up-front - The index can deal with much more complex things, like the spatial index which can even index a complete sub-graph as a geometrical shape in 2D space. This is not possible to express as key:value pairs on nodes or relationships, and so the initialization of the index itself needs to be done with an instance of the GeometryEncoder which explains to the index how to map the sub-graph into a Geometry, and thereby allows the RTree to understand how to index it. (my composite index also works like this since it needs to know up front the complete set of properties to index, because the tree is built based on all properties at the same time, and adding a new property later is hard, and requires re-balancing the entire tree). What this means for the Ruby case is that, as far as I am away, neo4j.rb already simplifies the current index to work better with an object model, where each node represents an instance of a class and can be added to the index without properties. So we are already part of the way to what I want. So IMHO, forcing the spatial index to match the standard index API does not make like easier for the Ruby (or other) API. I think the Ruby wrappers can wrap the spatial index in a way that makes it as easy (or even identical) to the Ruby wrapper on the lucene index, but this does not require any intermediate java code to make the java spatial index look more like the lucene one. On Fri, Nov 26, 2010 at 4:54 PM, Peter Neubauer peter.neuba...@neotechnology.com wrote: Thanks for the feedback! On the GoeSpatial side, I am trying to get the setup easier, so for normal stuff, you don't have to go through GeoTeools but can use the Neo4j Index setup, see https://github.com/neo4j/neo4j-spatial/blob/300f4d1d1fbb92d6252d5be6dc334250c9514bc7/src/test/java/org/neo4j/gis/spatial/IndexProviderTest.java#L51 after just including Neo4j-Spatial into your dependencies. This syntax might make it easier to expose things in Ruby, REST and others, too. WDYT? For the heavy query lifting and GIS stack integration, the GeoTools API is the way to go though ... Date support in Neo4j is a very interesting thing that I think needs a bit of thought. Thanks for pointing it out - would be a great lab-friday project :) Cheers, /peter neubauer GTalk: neubauer.peter Skype peter.neubauer Phone +46 704 106975 LinkedIn http://www.linkedin.com/in/neubauer Twitter http://twitter.com/peterneubauer http://www.neo4j.org - Your high performance graph database. http://www.thoughtmade.com - Scandinavia's coolest Bring-a-Thing party. On Fri, Nov 26, 2010 at 3:08 PM, Javier de la Rosa ver...@gmail.com wrote: On Fri, Nov 26, 2010 at 02:03, Peter Neubauer peter.neuba...@neotechnology.com wrote: Btw, what does everyone feel about REST vs. native protocols like RMI, Protobuffers, etc that can support a full Neo4j remote API for integration, with TX etc and would be optimized for driver development in other langs, minicing the Java core API capabilities very close? Any thoughts or preferences on one or the other? Does REST do a sufficiently good job for production use from other langs? What would you like to see in REST to get there - top 3 features? My 3 cents: - Sockets maybe? - Support for Dates, and not only dates after Linux Epoch. - Support for do traversal with the geospatial information. Using GeoJSON or WKT? -- Javier de la Rosa http://versae.es ___ 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
Re: [Neo4j] Release 1.0.0.beta.22
Any mechanism that make possible to build traversals with geospatial information through the REST API would be great. So, in some moment in the future, will be possible do traversals with geodata?, I mean, build traversals in which I could asking the nodes using geospatial operations like near, is a point of, overlap with, to a distance less than, etc. I think it should be relatively easy to add spatial extensions to the REST server, but I've not been involved in the REST project much, so I'd need to discuss this with others. Since the current REST API is based on JSON, the preferred choice for the geometries would be GeoJSON, and I think it would be nice to embed the GeoJSON objects directly in the REST JSON response itself. Alternatively your idea of WKT embedded in a JSON value might work well too. We might need some clever tricks to deal with paging large result sets, but I guess that is an issue for all database queries. Deployment wise I think it would be great if simply adding the neo4j-spatial jar to the Neo4j Server deployment would activate a few spatial queries that could be used. I do not really agree with Peter that spatial can be slipped behind existing API's. I think many, or most things, will require specific spatial queries and spatial responses. I certainly believe this is true of your suggested queries above: near, point of, overlaps with, etc. Cheers, Craig ___ Neo4j mailing list User@lists.neo4j.org https://lists.neo4j.org/mailman/listinfo/user
Re: [Neo4j] Release 1.0.0.beta.22
Great stuff Andreas, we had a great evening in Barcelona yesterday, showing off the great work you, Ben and all the others are doing! Fantastic API and features! Craig and me are working on getting the Neo4j Spatial supported (at least the basic features) as a normal index provider in Neo4j. That would mean that you then in Neo4j.rb can directly ask not only text queries with Lucene but even spatial queries. Would be very cool to get that in, too :) Btw, what does everyone feel about REST vs. native protocols like RMI, Protobuffers, etc that can support a full Neo4j remote API for integration, with TX etc and would be optimized for driver development in other langs, minicing the Java core API capabilities very close? Any thoughts or preferences on one or the other? Does REST do a sufficiently good job for production use from other langs? What would you like to see in REST to get there - top 3 features? We are just trying to figure out the best way to expose and support the different Remote options ... Cheers, /peter neubauer GTalk: neubauer.peter Skype peter.neubauer Phone +46 704 106975 LinkedIn http://www.linkedin.com/in/neubauer Twitter http://twitter.com/peterneubauer http://www.neo4j.org - Your high performance graph database. http://www.thoughtmade.com - Scandinavia's coolest Bring-a-Thing party. On Thu, Nov 25, 2010 at 8:00 PM, Andreas Ronge andreas.ro...@gmail.com wrote: Hi I've just released 1.0.0.beta.22 The big news is that you can now use the rails console while the rails application is already running. I first tried to access neo4j remotely via RMI and DRb but there were to many problems doing that, so instead I simply create a read only neo4j db when needed. CHANGELOG * If a neo4j write instance is already running it will instead start a read only neo4j db instance. * Upgrade JARS to 1.2.M04 * Does not automatically start Neo4j when used in Rails. E.g. now you can type rails routes without the database starting. -- You received this message because you are subscribed to the Google Groups neo4jrb group. To post to this group, send email to neo4...@googlegroups.com. To unsubscribe from this group, send email to neo4jrb+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/neo4jrb?hl=en. ___ Neo4j mailing list User@lists.neo4j.org https://lists.neo4j.org/mailman/listinfo/user
