Version 4 > Developer Guides > Transition Guide for Developers > Database Changes

Database Changes

Differences with the v3 schema are summarized in this table:

v3v4

ExSite::SQL

ExSite::MySQL

section, page, content

content (with a type column)

content_data

revision, view

member

user

member_site_link

content_key

keyword, keyword_tag

deprecated, replaced with Index class and aliases


Notes:

  • section_id columns contain the content_id of a content record of type “section”. They might be replaced with content_id columns, if they can be related to something more specific than a section.
  • member_id has generally been replaced with UID.

DB Maps

DB maps now support a help column. This replaces the old help files in cgi/dbmap/help/table/column. These columns will be used to automatically add tooltips to your forms.

The enum: datatype works like a list: datatype, except that it returns an integer value instead of the text value. For example:

list:onoff   on|off

returns text values of either "on" or "off".

enum:onoff   1:on|0:off

returns numeric values of 1 or 0, but displays text values of "on" or "off" to the user.

Attributes & Metadata

The attribute table (and ExSite::Attribute class) provides a generic metadata functionality, as in v3. This can be overloaded to provide a more dedicated/specialized metadata feature for specific tables or types of data. V4 has a few predefined specialized metadata tables/classes:

tableclassextendsnotes

attribute

ExSite::Attribute

any table

used for preferences

metadata

ExSite::Metadata

content

see v4 Content Model document

contact_info

Modules::ID::ContactInfo

contact

contact information fields

Use/inherit the ObjectMeta class on the extended object to get these metadata features. When calling the new() or setup() methods of the extended object, you can optionally pass a metadata option to preload the metadata. This can save some database reads in cases where you already have the data handy:

my $article = new ExSite::Article(id=>456, data=>$article, metadata=>$article_metadata);

my $contact = new Modules::ID::Contact(id=>123, data=>$contact_record, metadata=>$contact_info);

Object Handling

As in v3, an ExSite object is a software representation of a database record. This all works similarly to v3, with some efficiency enhancements.

You can preload your objects with partial data if you have some of the record data handy. Simply pass your incomplete datahash to the data=> parameter in new(). If getdata() requests data that is already present, no database load is required. But it needs an efficient way to check whether it needs to load the full record if the data is not present. See ExSite::Content::getdata() and ExSite::Content::loaded() for an example implementation of this feature.

The ObjectMeta class also lets you preload metadata into your objects if you happen to have it handy, which can also save on database calls. Pass the metadata as a hash of key=>value pairs.

my $content = new ExSite::Content(data=>$cdata,metadata=>\%meta);

The ObjectList class will try to track metadata as well, if you provide it, and use this feature to preload object metadata when you pull objects out of the list. To push a record and its metadata onto the list, use:

$list->pushmeta($record,$metadata);  # one object
$list->pushmeta(\@records,\@metadata);   # multiple objects

Not all list operations will be able to preserve the metadata. In those cases, the metadata might get cleared, which will force it to be reloaded from the database.

Objects also support an unload() method that tries to drop internal attributes that are no longer needed. This is useful when looping over large data sets, to keep memory leaks under control.

When working with lists of content objects, extracting an object from the list will return a content subtype class, eg. a Blog object instead of a generic Content object.

Security

There are now 10 access levels:

#old#namenotes

0

0

public

unauthenticated visitor

1

1

user

authenticated user

2

 

member

official or paid member

3

 

site-defined

board members, committee leads, ... ???

4

 

site-defined

 

5

 

site-defined

reviewers/moderators ???

6

 

site-defined

 

7

2

manager

can perform all section-specific admin tasks

8

3

system administrator

can perform system-wide tasks, can make keys

9

4

root

all security rules disabled

Levels 0-4 are regular website visitors, permitted to use the website front-end. Levels 5-9 are executive users, permitted to access the website back-end. Levels 3-7 are undefined for now, and can be used for customizing local site privileges.

DB maps must be upgraded to reflect this. Code should not test for absolute levels, but for user types. For example:

  • is_admin (level 8+)
  • is_manager (level 7+)
  • is_executive (level 5+)
  • is_visitor (level 4 or lower)
  • is_member (level 2+)
  • is_user (level 1+)

Privacy settings and access controls are now numeric. A privacy/access level of 2, for instance, means that the viewer must be at least level 2 (an active member) to view the data or access the function.

Groups

You can create user groups using the security tools, and assign or remove arbitrary users to/from these groups.

Keys

Access keys can be assigned for any content object, not just sections. (However, sections remain the default way of partitioning security.)

Access keys can also be revoked for particular content. To do this, set the key type to “revoke” instead of “grant”. Revoked keys disable a certain type of access in that part of the site. For example, say user Admin has editorial permissions on the main section. But on a particular page, you revoke those editorial permissions. The admin user’s permissions will not extend to that page, or any below it.

Keys can be granted to individual users, or to groups. Group keys can be used by everyone in that group.

Security Roles

v3 v4

editor, designer, administrator

editor, designer, administrator, reviewer, owner

The reviewer role controls moderation and approval of submitted and draft content.When new content requires approval, the reviewers will be consulted first.

The owner role is for content that originates from non-executive users. (For example, a regular member could have permission to publish content that they owned, such as postings, profiles, etc.)

If the auth.view_keys config option is enabled, any key will grant access to view a content object. That would allow you to grant specific users or groups permission to view admin-only content, for instance.

Configurations