Tagger Hack: Retrieving threads from db

it would simply take too much load to put custom fields for each message in a separate table!
another query for each message or all messages in one retrieval step.

---

Thomas Seifert

Even if you would have such a feature, then it would not really help with the tagging project, because the code in the database layer would still not be using it.

If custom storage is needed for a major feature, then you probably want to implement a custom table for that in the database. I can imagine that for tagging, you want to record more than only the tags. I would want to have track of who added the tags and when they did that, to be able to do some tagging abuse prevention.

---

Maurice Makaay
Phorum Development Team
my blog linkedin profile secret sauce

I think you underestimated the amount of workin I was asking for from you Maurice. I wasn't thinking of adding custom fields as a mod but rather to the core phorum dev. It is more of an idea for future programming than a practical solution now. I do think it would enhance the usability and customizability (word?) of phorum, but I realize it would take quite a bit of work to make it happen.

---

Joe Curia (aka Azumandias)
Modules: l0Admin Mass Email00000000l000000Automatic Time Zones000ll.l00000Enhanced Custom Profiles0.00Google Calendar0000l.l000000Post Previews
000000000Admin Security Suite000000000000Check Modules for Upgrades0000External Authentication000000Group Auto-Email00000.00000Private Message Alerts
000000000Attachment Download Counter0000Custom Attachment Icons000ll.ll00Favorite Forums000000.00000Highlighted Search Terms0000Self-Delete Posts Option
000000000Attachment Watermarks0l00000000Custom Language Database00l.l.0Forum Lockdown00000.00000Ignore Forums0000000000000Threaded Tree View
000000000Automatic Message Pruning00.llll.00Easy Color Scheme Manager0l.l00Forum Subscriptions0000lll000Moderated User Group
Templates:lGeneric Integration000000000 0000Simple Rounded000000 00000000Tabbed Emerald

I do understand that you are talking about the core and the amount of work is not the issue here. About the most valid point for not adding another table for linking individual setting fields to a message, is the performance of the system. We do have this system in place for users, but after implementing and running it, we found out that it performs badly. We really needed user caching then to maintain the Phorum speed.

My view is that for most of the fancy features for which you would want to store extra data in the database for a message, a separate table for storage is the best option. Or of course, extend the existing message table with extra fields. That gives full control over the data and gives you possibilities for adding multiple related fields on which you can query and indexes for speedy queries.

For simple message related storage, the meta data is a perfect and fast tool already and it would be bad to change that into a system which slows down Phorum.

---

Maurice Makaay
Phorum Development Team
my blog linkedin profile secret sauce