Jim,

To try answer my own question for auto bs manual. 

One think I like with manual is a situation where a client had multiple 
alsoknownas names which is a relationship IS_ALSO_KNOWN_AS

Now in this case with manual index I can actualy index a reference to client 
node using fields from nodes related to the client

Fn
Ln
Fn ln
Aka
Aka ln

So the last two index entries point to the Client Node address, this is great 
since in rest API we can control the node to point to for manual indexes, and 
thus I guess is why they perhaps are preferred over automatic.

But automatic is good for simple one to one non composite values??

Cheers

Sent from my iPhone

On 20/08/2011, at 9:10 AM, "Romiko Derbynew" <romiko.derby...@readify.net> 
wrote:

> Hi Jim
> 
> Thanks for the response. I have built a .Net API to manage manual indexes. So 
> basically when I create a node I have an option to parse in a collection of 
> key/Val pairs to index the node. I'm using Lucene and fulltext.
> 
> However it sounds like auto indexing might be a better option? I avoided it 
> as the docs mention experimental and I was not sure if you can configure 
> exactly which fields to index, but it seems after reading your profile that 
> this is possible via config. So is it possible via config to do this:
> 
> Imagine a customer node, with firstname, lastname, preferredname.
> 
> In my current implementtion I add the following into ONE fulltext index
> Key:Name
> Value permutations for same key:
> Fn
> Ln
> Pn
> Fn ln
> Pn ln
> 
> This means people can search 
> bob brown
> Bobby brown
> Brown
> Bob
> Bobby
> Bo~
> browns~
> 
> How would you configure this in the config file for autoindexing? I did not 
> know that autoindexing could be fine grained control, which will make code 
> maintenance much easier.
> 
> The last question then is when should manual be used over auto?
> 
> Much appreciated.
> 
> Sent from my iPhonen
> 
> On 17/08/2011, at 12:19 AM, "Jim Webber" <j...@neotechnology.com> wrote:
> 
>> G'day Romiko,
>> 
>>> *       Configuration File: Autoindexing enabled here is related to 
>>> automatically indexing all nodes and relationships?
>>> *
>>> 
>>> If I want to add a node to an index following the guidelines, what 
>>> convention should be used for the Key/Value naming? Imagine we have nodes 
>>> of type Customers, and we have 10000 customers, what sort of key/value 
>>> would we set for each customer, as I would guess that all properties are 
>>> indexed for the node? Would it be perhaps a unique auto increment number 
>>> for example that is in no way related to the data node?
>> 
>> The basic mechanics are straightforward: Assuming you've configured your 
>> indexes 
>> (http://docs.neo4j.org/chunked/snapshot/auto-indexing.html#auto-indexing-config),
>>  then there's nothing more to do. Every time you encounter a node (or 
>> relationship) with one of the properties that you declared in your config, 
>> it'll be added to the index if it wasn't before, and the property value will 
>> be in sync with the value in the node (or relationship).
>> 
>> Only the properties that you ask to be auto-indexed will be. So in your 
>> case, you might well have an auto index config that indexes only (say) 
>> customer_id and doesn't care about other properties.
>> 
>>> *       Also, how can we control the properties/fields to index when we add 
>>> a node to an index with the RestApi, I would imagine we would not want to 
>>> index all fields on a node via the auto indexing feature?
>> 
>> 
>> At the moment you can't control auto indexing through the REST API, you can 
>> only use auto indexes that have been configured on the server. I recall Jake 
>> (I think) mentioning this before, and it boils down to the fact that we 
>> don't mutate config (and so changes to auto index config isn't persisted 
>> across DB restarts). Once we figure out how to persist things like config in 
>> a database, we'll get stuck into that :-)
>> 
>> Jim
>> 
>> PS - thanks for prompting on this, it's triggered a good refactoring and 
>> cleanup of the index functional tests.
>> _______________________________________________
>> 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

Reply via email to