0

I've recently started working with Firebase and in one of the demo-apps I've implemented something tinder like. You can basically swipe users and after swiping one I'm storing the data in the following format/path:

matches/randomeFirebaseID()/{
userid: true
otherUserid: true
}

That's pretty nice to query them again BUT how can I make a security-rule that doesn't allow duplicated entries like that. Is that even possible with security-rules? Or should I structure the data in another form? It would be possible to simply query them beforehand and check if a match already exists, but that takes some extra time I don't want to waste.

Thanks for your help!

Community
  • 1
  • 1
Lukas
  • 1,346
  • 7
  • 24
  • 49
  • Since your parent node is generated randomly, it wouldn't ever be a duplicate. Are you referring to the userid node? In general, Firebase rules are not designed to filter data. Please check out [Securing Your Data](https://www.firebase.com/docs/security/guide/securing-data.html) and in particular the Existing Data vs New Data section and most importantly the Rules Are Not Filters Section. Your best bet is a query which will be super quick and won't really add any overhead to speak of. – Jay May 01 '16 at 14:37
  • Hey Jay, yes, I don't want duplicated "matches" for the same 2 guys. I was concerned that it would be a little and is not "best practice" but i will give it a try! Thanks! – Lukas May 01 '16 at 14:52
  • It sounds like you should generate the key based on the two uids. See my answer here: http://stackoverflow.com/questions/33540479/best-way-to-manage-chat-channels-in-firebase/33547123#33547123 – Frank van Puffelen May 01 '16 at 14:57
  • That's what i was thinking too, but i couldn't really figure out how to handle "who is first" problem. But your link helps! Thanks – Lukas May 01 '16 at 15:42

1 Answers1

5

For anyone who's interested. The solution was pretty simple, well as always :)

I used a mix of both userid's as key of a conversation. And in order to know, which one goes first, i simply ordered them, so they are always arranged the same way.

Example: userid1: abcde userid2: zudfg

so the conversation id would be: abcdezudfg

That makes it pretty easy to access it or even check weather a conversation between these users already exist or not.

I hope this helps.

Lukas
  • 1,346
  • 7
  • 24
  • 49