Once you have decided on your typing scenario, you can create one generic call back and make the parametrization declarative. A generic call back may be as thin as hooking up a prolog engine and declaratively define the different rules to be applied for you indexing scenario. Niels
> From: rick.bullo...@thingworx.com > To: user@lists.neo4j.org > Date: Mon, 18 Jul 2011 06:02:05 -0700 > Subject: Re: [Neo4j] Auto-index fulltext? > > We manage that today using Neo. Node "types" are represented by an array > property on the node - therefore a node can be of many "types". We then > utilize relationships to provide an "implements" relationship that enables > arbitrarily deep and complex inheritance/implementation scenarios. > > My core point was that something better than "primitive type" is clearly > needed, and a "node type" is a step in the right direction. As Peter points > out, it's one. > > That said, if you make it overly complex to support every possible scenario, > then you've pretty much defeated the benefit of "auto indexing" in the first > place. The logic to decide which index to use (and the associated code > behind) could easily be as complex or more complex to maintain than > application level code. Callbacks and such are just another form of "code", > so it really doesn't seem to me to be the "auto indexing" scenario. "Auto" > indexing should be declarative, shouldn't it? > > I prefer to make the "easy stuff easy and the hard stuff possible" - and that > implies using simple, easy-to-implement and easy-to-maintain patterns for the > stuff that 95% of applications need, and API-based approaches for the other > 5%. > > > > -----Original Message----- > From: user-boun...@lists.neo4j.org [mailto:user-boun...@lists.neo4j.org] On > Behalf Of Niels Hoogeveen > Sent: Monday, July 18, 2011 8:50 AM > To: user@lists.neo4j.org > Subject: Re: [Neo4j] Auto-index fulltext? > > > Rick, > I think adding a "node type" to neo4j is not a good idea. Different > applications have different typing needs. > > My own application for example, supports multiple "node types" per node, > while "node types" can be subtyped as well. > This creates a forest of types for each node, that needs to be traversed each > time the typing information of a node is requested. > Morever the INSTANCE_OF relationships are stored as and Indexed Relationship > (https://github.com/peterneubauer/graph-collections/tree/master/src/main/java/org/neo4j/collections/indexedrelationship), > > because certain types can have millions of instances. > I am certain that such a typing construct is not everybody's cup of tea and I > wouldn't want to see it formally supported in core. > Neither would I want to see support for typing constructs other than the one > I use. > Being a schemaless database is one of the strengths of Neo4J, and typing > shouldn't become part of the core distribution.That said, there are good > reasons to create different typing libraries as a layer on top of Neo4J, the > meta model component, > though in need of some attention, is one such layer. > For auto-indexing purposes, I would much rather see the addition of an > installable call back function that takes:the node, the key, the value and > the index as input and returns the value to be indexed or null if no indexing > should take place. > Niels > > > > > > From: rick.bullo...@thingworx.com > > To: chris.gio...@neotechnology.com; user@lists.neo4j.org > > Date: Mon, 18 Jul 2011 05:15:08 -0700 > > Subject: Re: [Neo4j] Auto-index fulltext? > > > > 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 > _______________________________________________ > 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
