How to structure this index/query problem

[martinjuhasz (Martin)]

Hey,
i'm pretty new to using ES and wonder how one would solve my current problem, regarding how to index this best and how to query it.

As an example lets say i have two entities in my application. Users and Challenges.

What i want to do now is beeing able to list the following:

• list all challenges for a user , either all, only the ones he declined or only the ones he accepted
• list all challenges and how many have accpeted those

How would i index and query the part of accepting/declining challenges?

What i did for now is to index challenges and users, each in their own index. I'm able to query/filter etc challenges and users without problem.

What i fail to is to come up with a good way to query my additional needs.
Thanks for any hints about this!

[dadoonet (David Pilato)]

Welcome!

As all entities you are searching for are challenges, I'd only index challenges.

And each challenge would have all the information about the user who ran that challenge.

[martinjuhasz (Martin)]

so basically if i get you right... have one document per challenge which includes a property of all the id's of users that took the challenge and another prop for those who declined?

[dadoonet (David Pilato)]

I meant one document per challenge a single user ran.
The same challenge will be duplicated as many times as needed but with other user details.

My 2 cents.

[martinjuhasz (Martin)]

Ok interesting. How would i handle changes in the challenge entity then? f.e. one property changed (challenge name) across all documents with duplicated data?

Also how would one query "all challenges" not depending on a user without duplication?

[dadoonet (David Pilato)]

You can reindex all the documents that needs to be reindexed when a challenge changes.
You have to have an idea of the cost behind. Ie are you going to reindex 10m documents? Or less than that? How much?

Also does it make sense to change a challenge that happened in the past after a user has already submitted it? That's a business question of course.

About deduplication, may be aggregations would work for you.

Worse case, if you really need to have 2 distinct entities, have a look at the join data type also called parent/child. Although I'm not a big fan, your use case might be a good candidate for this feature.