But then, how about conditionals and more complex stuff like relationships connected to nodes, inferred type because of in-graph reasoning etc? Node Type as a simple String is not adding much over other recognizable patterns, and much less usable other than "crude" scenarios. If you want that, why not set a TYPE property and then (in future versions) link conditional auto-indexing to that?
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://startupbootcamp.org/ - Öresund - Innovation happens HERE. http://www.thoughtmade.com - Scandinavia's coolest Bring-a-Thing party. On Mon, Jul 18, 2011 at 2:15 PM, Rick Bullotta <rick.bullo...@thingworx.com> wrote: > Chris, I think that auto indexing is another great reason for a formal > concept of "node type". It could provide an unambiguous link between a node > and its indexing strategy(ies). > > > > ----- Reply message ----- > From: "Chris Gioran" <chris.gio...@neotechnology.com> > Date: Mon, Jul 18, 2011 6:16 am > Subject: [Neo4j] Auto-index fulltext? > To: "Neo4j user discussions" <user@lists.neo4j.org> > > No, that is not what i meant. The main idea is to provide the means to > configure at least some aspects of the auto index instead of relying > on the default settings only. There will still be one auto index for > each primitive category. > However, one feature under consideration is to actually allow an > arbitrary number of auto indexes, each of which will allow for > individual configuration. So, when that comes along you will have what > you described (and more, actually). > > thanks, > CG > > On Mon, Jul 18, 2011 at 12:29 PM, Aseem Kishore <aseem.kish...@gmail.com> > wrote: >> Awesome to hear, Chris, thanks. Just to clarify/confirm then: in the future, >> we will be able to have *both* an exact auto-index and a fulltext auto-index >> side-by-side? >> >> Cheers, >> Aseem >> >> On Mon, Jul 18, 2011 at 3:18 AM, Chris Gioran < >> chris.gio...@neotechnology.com> wrote: >> >>> Hi Aseem, >>> >>> On Sat, Jul 16, 2011 at 9:46 AM, Aseem Kishore <aseem.kish...@gmail.com> >>> wrote: >>> > Is the 1.4 auto-index only "exact"? Or can it be configured to be a >>> > "fulltext" index? >>> >>> Yes, currently the auto-indexes are only exact, there is no >>> straightforward way to configure them explicitly. This is a known >>> shortcoming and will be remedied pretty soon. >>> Another addition that is coming, by the way, is the visibility of >>> changes of the auto index within the transaction, instead of waiting >>> for commit time as is now. >>> >>> > (Btw, it would be awesome if we could have two auto-indexes: one exact, >>> one >>> > full-text. It would be great in general if all indexing could be auto. >>> Not >>> > sure when you would ever want/need manual indexing.) >>> >>> Well, a lot of use cases call for manual indexing, when for example it >>> is conditional or the use of multiple indexes is required. If, >>> however, auto indexing covers all your needs then by all means, do >>> just that. >>> >>> cheers, >>> CG >>> >>> > Aseem >>> > _______________________________________________ >>> > 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 >> > _______________________________________________ > 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
