Our WebChat workflow will be simple. If you try to access the system and aren't logged in it will route you to a login page (login.php). If you're not registered, you can go to the registration page (register.php), and from there log in. Once you're logged in, you are routed to the chat page (chat.php) and can engage in chat with other logged-in users: you can add a comment or delete your own comments. From there you can log out (logout.php). This workflow is summarized in Figure 1.
Let's think a little bit about how we're going to store our user
information. As mentioned previously, there are no SQL style
schemas in Couchbase, only keys and values. In addition, we can't
enumerate a list of keys in the Couchbase bucket we're using. This
means we have to know what we're looking for before we look; we
* from TABLE as we would using an
SQL query. Also, even assuming we've only got one application
using the given bucket, care must be taken in key naming
conventions so that collisions don't occur with keys of different
For our keys, we'll prefix each key first with the application name, then the key type, for example a user named jsmith will get a user key in Couchbase of chat::user::jsmith, where the value associated with that key will contain the account information. We're prefacing the user key with the application name in case we later choose to share this bucket with another application; if all applications follow this convention we're creating a namespace for each application and we can be avoid key collisions between apps.
For the user comments we'll keep a single key that lists the maximum comment number so far achieved, and the comments themselves will have keys containing their comment number, for example, chat::COMMENT#23
This is another method of determining the keys for values we may want to retrieve, somewhat different from that of the user list discussed above.
Though we won't be implementing an administration function for
managing users in this example application, we want to design our
data model to support that possibility. This means that it should
be possible to enumerate all users. To allow this, for each user
we add, we'll append the username to a string held in the key
chat::userlist. We'll be using the API
append() method to that this.
append() is functionally equivalent to doing a
get() on the key, appending the new user to the
returned text, and storing it again. The
append() method requires less code and is also
atomic, while a get, modify, and update sequence would not be.
The value held by a given key is of a default maximum size of 1 megabyte, though it can be increased with server side configuration. This should be kept in mind if you are, for example, doing many appends in long running or large-scale applications that are likely to exceed this limit.