Building extensions for Pagekit Part #7 - The database
This post is older than 365 days and may be outdated. Please use the site-search to search for updated information.
Wow - it took quite a while, but today I am going to continue my series "Building extensions for Pagekit".
Today we will have a look at the database.
Well - Pagekit always uses a database. At the moment Pagekit supports
MariaDB. The good thing is: You don't have to care, which database is used.
Pagekit provides something like a database wrapper, a layer between Pagekit and the database. The queries you are working with are always looking the same. Pagekit takes care of the "translation".
This is a really important point, as different databases could use a different query syntax. You don't have to care about this.
Why do we need a database?
In our last lessons we learned that Pagekit provides a really handy way to store data. The
This config is defined at
index.php just like this:
'config' => [ 'restrict' => true ],
So we could just use this config to store our surveys, right?
Of course we could do something like:
'config' => [ 'restrict' => true, 'surveys' =>  ],
This would create an array for the config entity
surveys. We could easily store stuff in there. But it would be really horrible to do stuff like
joining tables or
SQL is the way to go. And Pagekit provides a lot of cool things for database handling.
Having a look at the official documentation we can get our first impression.
Your database contains a lot of
tables. These tables are named like
pk_system_user. Well - the name of the
system_user, but it has a prefix - in this case it's
As you are free to change your prefix to almost everything you want, it would not be a good idea to access the table this way. If you are writing an extension for your Pagekit instance, it would be fine, if you query your database using
pk_system_user. But if another user is going to use your extension having another prefix, your extension is not going to work.
Pagekit comes with an easy solution: Forget about the prefix. You can access your databases by using the name of the database (without the prefix) by just adding an
@system_user is going to be translated to
pk_system_user, if your database prefix is
pk. If your prefix is
h8, Pagekit is going to translate
Now we would like to create a database for our extension. Let's think about the way this database should be designed.
The design of our database is a really important step. You should always think about the way you are designing the database.
In our case we need an
ID for each survey. The
ID has to be an integer, unique and should always be incremeted. This is the best way to get unique data sets. If we would use another identifier, e.g. the title, we could possibly get in trouble, if the title of a survey already exists.
We also need a place for the
title. As the
title contains words, we need to store
strings in it.
We also need a table for our
questions and the
possible answers. And of course we would have to store the answers the user gave.
So this is your homework. Think about the structure of the extension. Grab a pen, draw a table and think about possible rows and relations.
I will publish a possible solution within the next week.