|
1 .. -*- coding: utf-8 -*- |
|
2 |
|
3 Creation of your first instance |
|
4 =============================== |
|
5 |
|
6 Instance creation |
|
7 ----------------- |
|
8 |
|
9 Now that we created a cube, we can create an instance and access it via a web |
|
10 browser. We will use a `all-in-one` configuration to simplify things :: |
|
11 |
|
12 cubicweb-ctl create -c all-in-one mycube myinstance |
|
13 |
|
14 .. note:: |
|
15 Please note that we created a new cube for a demo purposes but |
|
16 you could have used an existing cube available in our standard library |
|
17 such as blog or person for example. |
|
18 |
|
19 A series of questions will be prompted to you, the default answer is usually |
|
20 sufficient. You can anyway modify the configuration later on by editing |
|
21 configuration files. When a login/password are requested to access the database |
|
22 please use the credentials you created at the time you configured the database |
|
23 (:ref:`PostgresqlConfiguration`). |
|
24 |
|
25 It is important to distinguish here the user used to access the database and the |
|
26 user used to login to the cubicweb instance. When an instance starts, it uses |
|
27 the login/password for the database to get the schema and handle low level |
|
28 transaction. But, when :command:`cubicweb-ctl create` asks for a manager |
|
29 login/psswd of *CubicWeb*, it refers to the user you will use during the |
|
30 development to administrate your web instance. It will be possible, later on, |
|
31 to use this user to create other users for your final web instance. |
|
32 |
|
33 |
|
34 Instance administration |
|
35 ----------------------- |
|
36 |
|
37 start / stop |
|
38 ~~~~~~~~~~~~ |
|
39 |
|
40 When this command is completed, the definition of your instance is |
|
41 located in :file:`~/etc/cubicweb.d/myinstance/*`. To launch it, you |
|
42 just type :: |
|
43 |
|
44 cubicweb-ctl start -D myinstance |
|
45 |
|
46 The option `-D` specifies the *debug mode* : the instance is not |
|
47 running in server mode and does not disconnect from the terminal, |
|
48 which simplifies debugging in case the instance is not properly |
|
49 launched. You can see how it looks by visiting the URL |
|
50 `http://localhost:8080` (the port number depends of your |
|
51 configuration). To login, please use the cubicweb administrator |
|
52 login/password you defined when you created the instance. |
|
53 |
|
54 To shutdown the instance, Crtl-C in the terminal window is enough. |
|
55 If you did not use the option `-D`, then type :: |
|
56 |
|
57 cubicweb-ctl stop myinstance |
|
58 |
|
59 This is it! All is settled down to start developping your data model... |
|
60 |
|
61 .. note:: |
|
62 |
|
63 The output of `cubicweb-ctl start -D myinstance` can be |
|
64 overwhelming. It is possible to reduce the log level with the |
|
65 `--loglevel` parameter as in `cubicweb-ctl start -D myinstance -l |
|
66 info` to filter out all logs under `info` gravity. |
|
67 |
|
68 upgrade |
|
69 ~~~~~~~ |
|
70 |
|
71 A manual upgrade step is necessary whenever a new version of CubicWeb or |
|
72 a cube is installed, in order to synchronise the instance's |
|
73 configuration and schema with the new code. The command is:: |
|
74 |
|
75 cubicweb-ctl upgrade myinstance |
|
76 |
|
77 A series of questions will be asked. It always starts with a proposal |
|
78 to make a backup of your sources (where it applies). Unless you know |
|
79 exactly what you are doing (i.e. typically fiddling in debug mode, but |
|
80 definitely NOT migrating a production instance), you should answer YES |
|
81 to that. |
|
82 |
|
83 The remaining questions concern the migration steps of |cubicweb|, |
|
84 then of the cubes that form the whole application, in reverse |
|
85 dependency order. |
|
86 |
|
87 In principle, if the migration scripts have been properly written and |
|
88 tested, you should answer YES to all questions. |
|
89 |
|
90 Somtimes, typically while debugging a migration script, something goes |
|
91 wrong and the migration fails. Unfortunately the databse may be in an |
|
92 incoherent state. You have two options here: |
|
93 |
|
94 * fix the bug, restore the database and restart the migration process |
|
95 from scratch (quite recommended in a production environement) |
|
96 |
|
97 * try to replay the migration up to the last successful commit, that |
|
98 is answering NO to all questions up to the step that failed, and |
|
99 finish by answering YES to the remaining questions. |
|
100 |