Hi Roberto and everyone.
Thank you for your answer.
The redefinition showed was wrong, we don't do that.
We remove all the lucene full text indexes from subclasses. Instead, we add
a property string to put the @class.asString() in the objects and we add it
in the lucene index do enable class search.
Solved all the problems except one behavior that is related to drop a
class.
We have a lucene index in a class and we extend the class in a subclass, if
we drop the subclass the rebuild index * is called.
About the "allowLeadingWildcard", but guys here love asterisk, so we will
keep it enable from now.
Best regards.
André
Em sexta-feira, 17 de fevereiro de 2017 12:21:37 UTC-2, Roberto Franchini
escreveu:
>
>
>
> On Fri, 17 Feb 2017 at 14:36 André Toscano <andre....@gmail.com
> <javascript:>> wrote:
>
>> Hi Luca and everyone
>> I will describe our use case and make a question about Lucene indexes.
>> We developed a hybrid schema in Orientdb defining classes storing
>> documents (nested) and since we love Lucene indexes to enable their use we
>> always dump a document into a string property.
>> To establish the ER we use the direct approach to define Vertexes as
>> Entities and Edges as Relationships.
>> So the basic schema can be describe in oSQL:
>>
>> create class Entities extends V
>> create property Entitites.sdoc STRING
>> create property Entities.location EMBEDDED OPoint
>> create create index Entity.location ON Entity(location) SPATIAL ENGINE
>> LUCENE
>> create index Entity.ssdoc on Entity(sdoc) FULLTEXT ENGINE LUCENE METADATA
>> {"allowLeadingWildcard": true}
>>
>
> fixed from typos:
>
> create class Entities extends V
> create property Entities.sdoc STRING
> create property Entities.location EMBEDDED OPoint
> create index Entities.location ON Entities(location) SPATIAL ENGINE LUCENE
> create index Entities.ssdoc on Entities(sdoc) FULLTEXT ENGINE LUCENE
> METADATA {"allowLeadingWildcard": true}
>
> [cut]
>
>
>> and
>>
>> Create Vertex Companies content
>> {'key':{'key2':'value1','keylist':[1,2,3,4]},'key3':
>> 10,'key':[{'key4':'values'}]} RETURN @rid
>> update <@rid above1> set location = [-39.0,18]
>> update <@rid above1> set sdoc =
>> "{'key':{'key2':'value1','keylist':[1,2,3,4]},'key3':
>> 10,'key':[{'key4':'values'}]}"
>>
>>
> Ok, even this commands are wrong, location is an OPoint. I guess it's il
> almost psedo-code
>
>
>
>
>> Suppose that we have a contract between the two companies, so we would
>> create:
>>
>> create class Contracts extends Relationships
>> create property Relationships.sdoc STRING
>> create index Relationships.ssdoc on Relationships(sdoc) FULLTEXT ENGINE
>> LUCENE METADATA {"allowLeadingWildcard": true}
>>
>>
> Why are you re-defining props and indexes at the sub-class level? Is it
> only a typo ora re you doing it for real?
>
> [cut]
>
>>
>> Now, the problem:
>>
>> We keeping using the database like presented above and sometimes, when we
>> create and drop classes, the lucene indexes stops to work and we need to
>> execute:
>>
>> rebuild index *
>>
>
> My sugestio is to create lucene indexes only one time: on the superclass
> OR on the subclass
> Can you try defining the index only in one place and report if it break
> again?
>
> Moreove, my suggestion is to AVOID "allowLeadingWildcard", it will slow
> down your search and it is a "wrong" way to work with lucene :) (but maybe
> you need to work this way)
>
>
> --
> Best regards,
>
> Roberto Franchini
>
> OrientDB LTD - http://orientdb.com
>
--
---
You received this message because you are subscribed to the Google Groups
"OrientDB" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to orient-database+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
