From Habari Project

Contents 1 Tables 1.1 commentinfo 1.2 comments 1.3 crontab 1.4 groups 1.5 groups_permissions 1.6 log 1.7 log_types 1.8 options 1.9 permissions 1.10 postinfo 1.11 posts 1.12 poststatus 1.13 posttype 1.14 rewrite_rules 1.15 sessions 1.16 tag2post 1.17 tags 1.18 userinfo 1.19 users 1.20 users_groups 2 Notes and Questions

Tables

Note: The schema below applies to revision 2230

commentinfo

• comment_id (Primary)
• name (Primary)
• type
• value

comments

• id (Primary)
• post_id
• name
• email
• url
• ip
• content
• status
• date
• type

crontab

• cron_id (Priamary)
• name
• callback
• last_run
• increment
• next_run
• start_time
• end_time
• result
• notify
• cron_class
• description

groups

• id (Primary)
• name

groups_permissions

• id (Primary)
• group_id
• permission_id
• denied

log

• id (Primary)
• user_id
• type_id
• severity_id
• message
• data
• timestamp
• ip

log_types

• id (Primary)
• module
• type

options

• name (Priamry)
• type
• value

permissions

• id (Primary)
• name
• description

postinfo

• post_id (Priamry)
• name (Priamry)
• type
• value

posts

• id (Primary
• slug
• content_type
• title
• guid
• content
• cached_content
• user_id
• status
• pubdate
• updated

poststatus

• id (Primary)
• name
• internal

posttype

• id (Primary)
• name
• active

rewrite_rules

• rule_id (Primary)
• name
• parse_regex
• build_str
• handler
• action
• priority
• is_active
• rule_class
• description

sessions

• token
• subnet
• expires
• ua
• user_id
• data

tag2post

• tag_id (Primary)
• post_id (Primary)

tags

• id (Primary)
• tag_text
• tag_slug

userinfo

• user_id (Primary)
• name (Primary)
• type
• value

users

• id (Primary)
• username
• email
• password (SHA512 encrypted

users_groups

id (Primary) user_id group_id

Notes and Questions

Please delete any of the below if/when obsolete. Please use the user groups to submit any further comments.

• Does it make sense not to use AUTO_INCREMENT IDs and instead index by what is most often looked up?
• Uing GMT for all timestamps?
• what values should we support for "status"?
  • public
  • private
  • draft

• Could just create new users per comment author with no permissions and join the tables.
  • RCB: +1
  • SDM: -1 :This would potentially create a LOT of "users", especially when one posts a popular / controversial item that generates a lot of comments. Chris' idea below is an appealing solution.
  • CJD: As an alternative, we can periodically (or on comment creation) check the number of comments from the author and if it hits a certain threshhold, we create an account and give them karma?
• chris: I would like to have tracks and pings seperated out from comments, since they are not the same thing. I am not sure if that should be through splitting them out to a new table, or using some kind of type decleration.