Creating indexes on embedded maps/objects fails

[dcardin]

class Customer { address: { address..., city...., postalCode... } }

create index CustomerAddress on Customer(address.address) NOTUNIQUE (or FULLTEXT etc.)

responds with :

com.orientechnologies.orient.core.index.OIndexException: Index with name : 'CustomerAddress' cannot be created on class : 'Customer' because field: 'address.address' is absent in class definition.

After discussion with Luca, it appears that this might just be the property check that is failing even though the indexing could work.

I will be pushing a test case soon. Thanks!

[dcardin]

@laa what is the target milestone for this bug?

[lvca]

@laa can you put this in 2.0 Final?

[dcardin]

Just as an added note, it's kind of implied that we're able to reference those index in where clauses... select from Customer where address.address lucene ' .... ' or select * from Customer where [address.address, address.city] LUCENE "(prop1:foo AND props2:bar)"

[andrii0lomakin]

Guys it is impossible to fix till @tglman will not implement new dirty manager. So I postopone this issue.

[dcardin]

@laa could this be included in 2.1 ? I don't know about the new dirty manager mentioned by you in November 2014.

[dcardin]

@lvca has there been progress on this one? or should it be closed ?

[lvca]

@tglman is already working on Dirty Manager, but this is scheduled for 2.2

[a-unite]

+1 waiting for this feature

[micha-heigl]

I had the same problem and realized that #3548 gives a workaround. The problem seems to be that the automatic key type detection fails for idexes on embedded properties. So just set the key-type explicitely, e.g. create index CustomerAddress on Customer(address.address) NOTUNIQUE STRING

However there still seems to be a problem with this kind of indexes as they don't get auto updated on changes. I tried the following example:

create class Account
create property Account.email string

create class User extends V
create property User.account EMBEDDED Account
create index User.email on User(account.email) unique_hash_index string

insert into User set account = {"email":"john@mail.com"}
insert into User set account = {"email":"john@mail.com"}

The second insert is rejected as I expected. But as soon as I do

insert into User set account = {"email":"john2@mail.com"}
update User set account.email = "john@mail.com"

both queries pass and I have two accounts with the same email. Now the index is broken and I can't do any manual rebuild (OIndexException). On the broken index I can repeat the insert with the same email as often as I want, they all get created.

I don't know if this has anything to do with the dirty manager. Anyway in my opinion this creation issue seems to be resolved in contrary to #3548 which is still an issue on updates.

I tried this on 2.1.4 and 2.1.6

PS: I already reported this issue a few days ago, don't know whether it got deleted or I did something wrong.

[a-unite]

Dear @lvca, will that feature (indexes on embedded fields) be released in 2.2.0? We are eagerly looking for it all this time. :)

[dcardin]

Is this issue still on target for 2.2.0 rc1 ?

[tglman]

hi,

Unluckely this feature is not in the rc1, so we have to move it to 3.0 or forward

[schernolyas]

HI!

The issue linked with https://github.com/orientechnologies/orientdb/issues/6061.

[dcardin]

This issue seems pretty complex to handle, but it's still the most important one for performance when using OrientDB as a Document container. I really hope you guys can make it available soon :D

[smolinari]

Not sure it is the exact same thing, but MongoDB has what they call a multi-key index for indexing sub-document arrays. https://docs.mongodb.com/manual/core/index-multikey/

Maybe it might help in building a concept for ODB 3.0, maybe it won't. But, I thought I'd mention it.

Scott

[robpayn]

I agree with dcardin that this is a critical feature if you are serious about the document database interface being useful, particularly to somebody used to MongoDB. A lack of ability to index the properties of embedded documents makes the ability to embed documents nearly useless.

[dcardin]

Is this stilll considered for 3.0 ? The milestone is out and this bug seems still in limbo.

[natsusenpai]

please make it available guys, I am looking forward to it

[ms123s]

Is this now implemented in 3.0.2

[schernolyas]

Hi @ms123s !

Thanks! I will check it for my application

[ms123s]

Sorry, but this was a Question from me. I have only forgotten the questionmark

[a-unite]

Guys, that was the roughest adrenaline-depression curve I've experienced in last years. Almost cried (hoorays) receiving message from @schernolyas, almost laughed (weeping) on the last comment from @ms123s...

[schernolyas]

HI @a-unite !

Hm ... What do you mean?

[dcardin]

@schernolyas What he meant was that he thought this bug was finally addressed by the team and he was super happy about it. Then he realized that it's still not fixed so he had a big up and down because of it. I raised this issue 4 years ago, and it is THE reason why I am not using Orient on my projects. I really thought it was the best product for document management, but not being to index sub-documents is seriously nuts.

Help us spread the love, guys @lvca @laa @luigidellaquila

[luigidellaquila]

Hi @dcardin

Thank you very much for your feedback, this feature is definitely important for us as well and we tried to add it to the roadmap more than once. Unfortunately, as you said, it's not there yet, but given the attention it has (and thanks to your comments and all the feedback on this issue) I'll try to raise it to the attention of the team again and see if we can speed up this development

Thanks

Luigi

[smolinari]

If ODB could index sub-document properties, I believe that would be a clear USP for ODB against other graph databases.

Scott

[dcardin]

It's very tempting to just close the issue after such a long time. I don't understand how your users can live without it. Has it been forgotten and lost?

[micha-heigl]

...issue after such a long time Has it been forgotten and lost?

jap, that's the reason why ODB is forgotten and lost in general. at least for us.