Activity DB Design Discussion
This thread has been created from this thread since the topic of discussion changed from syncing content to database and component architecture.
First of all, let’s clear a few things up:
1. The activity table is not a cache table, so the preconceived notions of what “cache” means don’t apply when considering solutions. It may contain data that has been pre formatted, but it still contains all the pointers back to the original content. It is quite possible to reconstruct all of the data from the information stored in the activity table. Remember “format_activity” functions?
The table is named “_cached” because this is a leave over from how the component used to work. I have not found a decent reliable way to change the name of the table that will not break a percentage of installations. This leads me onto number 2.
2. What people have talked about so far is the way the activity component used to work. It used to just be a table containing only pointers back to the original content. The stream would be re-built every four hours. The result would be populated in the “_cache” table which is a small part of what you see today. This would then be used to render the stream.
In reality this was just too expensive. Of course we can normalize the database until the cows come home, but in reality this isn’t going to cut it on a low end server. What I don’t want is for BuddyPress to be limited to high end servers with beautiful caching solutions. In reality, I want this thing to run on cheap hosts where someone can just throw it up there and it doesn’t take the server down.
Now, none of that is an excuse for poor database design – and I’m not saying BuddyPress has poor database design – but I’ll be the first to admit it could be better. Rome wasn’t built in a day, and I have no doubt that the schema is going to improve significantly over the next several versions and your help as a developer is appreciated. My philosophy is release early, often and iterate. No one is going to build a perfect solution straight off the bat, let’s get it out there and get people using it.
What we don’t want to do is start talking and discussing changes that fit the way things work right now. Here’s something to consider. I think the activity stream is going to be “the” central point to everything in BuddyPress. As an example, when the photos/album/gallery component is built, images will just be uploaded as an activity stream entry and appear on the activity stream. Any comments on the photo/photos will be activity stream comments. When you look at the permalink for that photo, it will just be an activity permalink with the comments showing.
What I’m saying is *everything* is an activity, regardless of what the content actually is. Rather than thinking of the activity stream as just a place where everything is aggregated, the activity stream will be the place where everything actually happens/is stored. The activity stream has almost everything you need now, powerful filtering, threaded commenting, permalinks and the ability to delete (and soon edit).
Separate interfaces could be built to perhaps display uploaded images in a different fashion, or private messages in a typical email style. However, in reality all of these are still activities.
You could compare this to the posts table in WordPress which is the heart of the software. Everything on the database level is considered a post, but on all levels above the database the content is defined by the “post_type”. Rather than creating multiple new tables for each content type, why not just use the activity table but be able to denote different types of content using identifiers or types?
These are all just ideas and nothing is anywhere near set in stone, however this all something to consider when talking about changes to the schema or debating how it works.
Let’s start some positive discussions about suggestions for small iterative improvements. But — I don’t want to hear about how WP does it wrong. At the end of the day WP is wildly successful and runs on most servers, fulfilling most people’s needs without a problem. Let’s keep it constructive.
- The topic ‘Activity DB Design Discussion’ is closed to new replies.