New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Move points out of user meta #90

Open
JDGrimes opened this Issue Jun 25, 2014 · 3 comments

Comments

1 participant
@JDGrimes
Member

JDGrimes commented Jun 25, 2014

This is, perhaps, a long-term project. I think we should consider moving the points values out of the user meta table. The table's performance leaves much to be desired, especially on large sites. The meta_key and meta_value columns aren't indexed, so most of our operations are probably pretty slow. I think this is something that can be achieved in a backward compatible manner, without too much effort. And I think the effort would be worth it.

@JDGrimes

This comment has been minimized.

Member

JDGrimes commented Jul 10, 2014

One thing that must be considered is that we currently offer the ability to specify a custom meta_key for a points type, providing instant integration with other plugins. We'd have to decide whether to preserve this feature (at the moment, I'd say "yes").

@JDGrimes JDGrimes added the breaking label Nov 17, 2014

@JDGrimes JDGrimes modified the milestone: 2.0 Feb 2, 2015

@JDGrimes

This comment has been minimized.

Member

JDGrimes commented Mar 21, 2015

An idea I've been toying with is abstracting out the underlying points API and making it storage agnostic. In other words, each points type could be stored in a different manner. This could be achieved by creating an abstract class (think "interface") where the methods add, get, set, etc. were abstract. Other methods needed would include get_top_users(). We'd also need each class to handle queries, too. Actually, logs queries would remain the same, but running other queries on the users points (not the logs) would need some treatment.

This would provide the benefit of making the plugin more versatile. However, it would also make it less extensible, in the sense that it would cramp extensions from directly querying/handling points, because they wouldn't know how they were stored. However, this could be partly overcome by providing an easy method of determining what features each points handler back-end thingy supported. Different back-ends could then provide support for non-core functionality at their discretion.

Another interesting aspect which could be explored if we go this route is abstracting points away from users. Sounds a little crazy, maybe, but I've had requests to make it so that a group of users can have collective points. This makes sense from a gaming perspective when you want to have teams that only earn collective points which don't affect the points of the individual. And beyond that, the possibilities are literally limitless. I don't want to bite off more that we can chew right now, but maybe we can consider laying the groundwork for something like this if we end up extracting the points type back-ends. I do fear that just that in itself could serve to over-complicate things, and this more so. But if done right, it should keep the plugin simple, while increasing extensibility exponentially.

@JDGrimes JDGrimes added extension-first and removed breaking labels Jun 6, 2015

@JDGrimes JDGrimes removed this from the 2.0.0 milestone Jun 6, 2015

@JDGrimes

This comment has been minimized.

Member

JDGrimes commented Jun 6, 2015

I think we need to explore this API as a module first before doing it, similar to what we are doing with the hooks API.

Also, this isn't backward-incompatible.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment