Pros and cons of independently tracking Badges

[haterecoil]

Hi !

First of all, good job on the lib : there is such a hole in Django's ecosystem.

I am currently in need of gamification for some django app of mine. At first I sketched something on my own and now I am looking at existing libs. Yours seems nice so maybe we could work together :D

This is between a feature request (which I could implement) and a discussion about your lib. I saw the issue "Feature Request" but still created a new Issue.

Question TL;DR:

• Why tracking badges independently?
• Why using linked list on badges?

In my sketch I thought about a scheme such as:

• Interface(FK)
• AwardCategory(name, description)
• AwardCategoryCounter(award_category, interface, points)
• Award(award_category, name, image, points_required)
• AwardEarned(award, interface)

I guess it would be a mix between Badge and Unlockable.

Pros:

• less rows in DB
• increment only AwardCategory, automatically reward Interface
• allow tracking Award with a counter rather than a linked list
• • not rebuilding xDefinition table each time a xDefinition is added (could also be fixed in the save method of xDefinition by implementing real linked list logic?)
• • easier to add / remove an Award, just implement some unique enforcement on Award(AwardCategory+points_required)

Cons:

• maybe more complicated to show all possible awards VS earned awards
• more models ?

Questions

• did you think about it already? so what?
• Would it be ok to add it to Unlockable ?

[mattjegan]

I'm not entirely sure what you're proposing, could you perhaps reword the problem? As for why we use definition models, it works nicely to be able to update or create a definition and have it update or create any badges you need automatically, now including chained badges 😄 To revoke some badge from a user, you would need to set the acquired property to false though I think it could be worthwhile adding a force_revoke() method to Badge.

Overall, the main concept is that all interfaces have all badges as instances already, however they don't necessarily have them acquired. Though this means there are more rows in the db, it also means that we can do quick lookups for what badges a user does and doesn't have without doing a number of joins or extra queries all over the place.

Does this explanation of the concepts help, I'm still a little confused what issue you've discovered?

[haterecoil]

Hi, thanks for the answer.

Does this explanation of the concepts help, I'm still a little confused what issue you've discovered?

Yes it does! And sorry I intended to add the question label to the issue, but I forgot about it.

I'm not entirely sure what you're proposing, could you perhaps reword the problem?

I am creating a django app similar to yours and I'm comparing possible db schemes.

I had three questions about your scheme: A) Why interfaces have all badges as instance? B) Why a linked list on Badges? C) Did you think about other implementations?

You answered A and partly answered B & C (you are optimizing for quick lookups, so chaining badges avoids using some counter as I did). Now, I better understand!

what issue you've discovered?

It does not suit my use case :p

GLHF, keep up the good work!

[mattjegan]

Glad I could've helped you @haterecoil and thanks for the discussion. Out of interest, what is the use case that this project doesn't meet? It might be worthwhile implementing a feature to meet it.