Hi Johan, missed to ask you about the indexing. See below. On 10/15/07, Johan Svensson <[EMAIL PROTECTED]> wrote: > Hi Klas, > > I've been looking some at the guide and you've done a great job. > > I think the last section about searching needs a bit more focus on > "design" though. Most of the time "searching by relations" will solve > the problem and a general rule for this kind of searching is to always > try to start the traversal where there are few relationships. > > Here is an example query "Give me all customers who's last name is > 'Nilsson' who live in Sweden and have ordered this item". > > If the application has 500000 customers of which 10000 live in Sweden > and the item has 1000 orders we should start the traversal from the > item traversing item->order->customer and finally filter on country > and the property 'last_name'. If the item constraint wasn't in the > query traversing country->customer would still result in a query time > of ms. >
I agree, we are missing a section in the search with the concept of searching using the Traversal api, and I am about to start working on that. As you say, this can help alot in many areas. But it won't take away the importance of searching by properties, something that is very common in enterprise systems, and many times, it will be impossible to solve using relationsship traversing. If we don't have it in the guide, I believe this will be the first thing people will ask for. > As you point out some attributes are better to index using a external > index utility instead of nodes/relationships. I've been working on > some index utilities lately that can be used to solve the problem > "give me all nodes with property x" but they can't do full text search > very well and that is where Lucene should be used. Great, this will definitely be needed and will replace the lucene solution in many (most?) cases. > Using Lucene as you describe in the guide will work but it will break > transaction safety. What we need to do is to make Lucene an XA-enabled > resource so it can participate in the transaction otherwise > inconsistencies can occur in case of a transaction rollback/jvm crash. True, and that reminds me, transaction handling is another topic that needs to be handled in the guide. > I suggest we remove the Lucene entry from the design guide for now and > put some work in creating a index-utility that will be easier to use. > We could even move the whole "search" part to a Design_Guide_Part2 > page since there is a lot to say about just that topic. > Ok, but I don't see the harm in having the chapter about Lucene for now? We could just add a row about using lucene not being transactional safe and it will be fixed soon. I just mailed about having the Linked customer and customer node tree as an example in a more advanced guide. I guess we could start that guide directly and add the lucene topic as the first entry. I can do that directly. What do you think? Best Regards Klas _______________________________________________ Neo mailing list [email protected] http://lists.neo4j.org/mailman/listinfo/user
