[GH-ISSUE #61 ] Allow dyndns to create host record if it doesn&#39;t exist #40

Author

Owner

@ivanfilippov commented on GitHub (Jul 1, 2016):

I like this idea in, but I'd like for it to be a setting, on a per domain basis. We don't have a way of setting per-domain settings yet but probably should look for into creating one.

@ngoduykhanh what do you think?

@ivanfilippov commented on GitHub (Jul 1, 2016): I like this idea in, but I'd like for it to be a setting, on a per domain basis. We don't have a way of setting per-domain settings yet but probably should look for into creating one. @ngoduykhanh what do you think?

kerem commented

Author

Owner

@trenb commented on GitHub (Jul 1, 2016):

Agreed. For us it allows newly provisioned hosts to be added to DNS as soon as they're turned up as we include ddclient as a standard part of our provisioning.

@trenb commented on GitHub (Jul 1, 2016): Agreed. For us it allows newly provisioned hosts to be added to DNS as soon as they're turned up as we include ddclient as a standard part of our provisioning.

kerem commented

Author

Owner

@ngoduykhanh commented on GitHub (Jul 2, 2016):

There is no public dyndns service provider allow to do this. Because of security and records management. But in internal use, in one of server provisioing step, using ddclient to provision the host's domain name is a really good idea.

I agree with you @ivanfilippov, this should be a setting. By default we won't allow this, but we can have a setting to "turn it on" for specific domains.

@ngoduykhanh commented on GitHub (Jul 2, 2016): There is no public dyndns service provider allow to do this. Because of security and records management. But in internal use, in one of server provisioing step, using ddclient to provision the host's domain name is a really good idea. I agree with you @ivanfilippov, this should be a setting. By default we won't allow this, but we can have a setting to "turn it on" for specific domains.

kerem commented

Author

Owner

@ivanfilippov commented on GitHub (Jul 2, 2016):

I have an implementation of domain specific settings almost ready with this
dyndns feature as the first use case. I'll submit it for review in the next
day or so.
On Jul 1, 2016 10:16 PM, "Khanh Ngo" notifications@github.com wrote:

There is no public dyndns service provider allow to do this. Because of
security and records management. But in internal use, in one of server
provisioing step, using ddclient to provision the host's domain name is a
really good idea.

I agree with you @ivanfilippov https://github.com/ivanfilippov, this
should be a setting. By default we won't allow this, but we can have a
setting to "turn it on" for specific domains.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/ngoduykhanh/PowerDNS-Admin/issues/61#issuecomment-230082511,
or mute the thread
https://github.com/notifications/unsubscribe/AAT5bh-SPZoATtZLvyjXsM3KSY3u1yOeks5qReYCgaJpZM4JDcmj
.

@ivanfilippov commented on GitHub (Jul 2, 2016): I have an implementation of domain specific settings almost ready with this dyndns feature as the first use case. I'll submit it for review in the next day or so. On Jul 1, 2016 10:16 PM, "Khanh Ngo" notifications@github.com wrote: > There is no public dyndns service provider allow to do this. Because of > security and records management. But in internal use, in one of server > provisioing step, using ddclient to provision the host's domain name is a > really good idea. > > I agree with you @ivanfilippov https://github.com/ivanfilippov, this > should be a setting. By default we won't allow this, but we can have a > setting to "turn it on" for specific domains. > > — > You are receiving this because you were mentioned. > Reply to this email directly, view it on GitHub > https://github.com/ngoduykhanh/PowerDNS-Admin/issues/61#issuecomment-230082511, > or mute the thread > https://github.com/notifications/unsubscribe/AAT5bh-SPZoATtZLvyjXsM3KSY3u1yOeks5qReYCgaJpZM4JDcmj > .

kerem commented

Author

Owner

@ivanfilippov commented on GitHub (Jul 2, 2016):

Hi @ngoduykhanh

Please review this new branch: https://github.com/ivanfilippov/PowerDNS-Admin/tree/per_domain_settings

If you don't see see any issues I'll submit a PR.

@trenb you're welcome to try that branch as well. 😄

You'll need to do a DB migrate/upgrade if you're not doing a fresh install.

@ivanfilippov commented on GitHub (Jul 2, 2016): Hi @ngoduykhanh Please review this new branch: https://github.com/ivanfilippov/PowerDNS-Admin/tree/per_domain_settings If you don't see see any issues I'll submit a PR. @trenb you're welcome to try that branch as well. :smile: You'll need to do a DB migrate/upgrade if you're not doing a fresh install.

kerem commented

Author

Owner

@ivanfilippov commented on GitHub (Jul 2, 2016):

@ngoduykhanh

I'm waiting for user testing on branch scriptroot_fix from #52, there is one place in the new per_domain_settings branch that will need the scriptroot_fix as well. Can you help test the scriptroot_fix branch? If it looks good I'll PR that and then update the per_domain_settings branch.

@ivanfilippov commented on GitHub (Jul 2, 2016): @ngoduykhanh I'm waiting for user testing on branch `scriptroot_fix` from #52, there is one place in the new `per_domain_settings` branch that will need the scriptroot_fix as well. Can you help test the `scriptroot_fix` branch? If it looks good I'll PR that and then update the `per_domain_settings` branch.

kerem commented

Author

Owner

@trenb commented on GitHub (Jul 2, 2016):

You'll need to do a DB migrate/upgrade if you're not doing a fresh install.

I get an error from both db_migrate.py and db_upgrade.py. They both complain about:

migrate.exceptions.InvalidRepositoryError: /var/www/html/PowerDNS-Admin/db_repository

Which there is no directory for that. Am I missing files from this branch? Also, where are the settings for enabling this feature? The settings screen is the same as it was before. And if I try to admin a domain, everything blows up, assuming because I'm not running the correct DB version.

Looking forward to trying this feature out! Thanks for your hard work!

@trenb commented on GitHub (Jul 2, 2016): > You'll need to do a DB migrate/upgrade if you're not doing a fresh install. I get an error from both db_migrate.py and db_upgrade.py. They both complain about: > migrate.exceptions.InvalidRepositoryError: /var/www/html/PowerDNS-Admin/db_repository Which there is no directory for that. Am I missing files from this branch? Also, where are the settings for enabling this feature? The settings screen is the same as it was before. And if I try to admin a domain, everything blows up, assuming because I'm not running the correct DB version. Looking forward to trying this feature out! Thanks for your hard work!

kerem commented

Author

Owner

@ngoduykhanh commented on GitHub (Jul 2, 2016):

Thanks @ivanfilippov for the quick implementation. I've tried your code but it doesn't work. There 2 issues I can see now are:

The checked box isn't checked after we applied the change successfully.
Cannot get the domain id which is allowed in the DomainSetting table (I've commented about the error in your code)

@trenb : The db_repository directory was created when you run create_db.py. I think you missed this directory somehow when clone the repository to new place and reuse the old database.

@ngoduykhanh commented on GitHub (Jul 2, 2016): Thanks @ivanfilippov for the quick implementation. I've tried your code but it doesn't work. There 2 issues I can see now are: - The checked box isn't checked after we applied the change successfully. - Cannot get the domain id which is allowed in the DomainSetting table (I've commented about the error in your code) @trenb : The `db_repository` directory was created when you run `create_db.py`. I think you missed this directory somehow when clone the repository to new place and reuse the old database.

kerem commented

Author

Owner

@trenb commented on GitHub (Jul 2, 2016):

@ngoduykhanh Aww. That original directory is long since gone. Is there a way to regenerate it?

@trenb commented on GitHub (Jul 2, 2016): @ngoduykhanh Aww. That original directory is long since gone. Is there a way to regenerate it?

kerem commented

Author

Owner

@trenb commented on GitHub (Jul 3, 2016):

@ngoduykhanh Ah well, I flattened my install and started fresh. I'll ensure I keep that db_repository directory, though it doesn't seem to actually be filled with anything other than empty py files.

@ivanfilippov The feature is tested and it does add the record. However it's marked as "disabled". Is this expected?

Thank you for your work! Let me know if you need any other information.

@trenb commented on GitHub (Jul 3, 2016): @ngoduykhanh Ah well, I flattened my install and started fresh. I'll ensure I keep that db_repository directory, though it doesn't seem to actually be filled with anything other than empty py files. @ivanfilippov The feature is tested and it does add the record. However it's marked as "disabled". Is this expected? Thank you for your work! Let me know if you need any other information.

kerem commented

Author

Owner

@ivanfilippov commented on GitHub (Jul 3, 2016):

@trenb You're right about the disabled thing. I've fixed that in the latest commit to that branch.

@ngoduykhanh I can't seem to replicate the checkbox issue on my side. When I check it, the browser does the javascript call and the checkbox stays checked after it succeeds. I'll keep trying to replicate but I'm probably missing something.

Also, for your comment in the code the DomainSetting.domain is actually a reference to a Domain object (via a relationship in the model) instead of just the domain name. It's working for me but did your fix solve an issue?

@ivanfilippov commented on GitHub (Jul 3, 2016): @trenb You're right about the disabled thing. I've fixed that in the latest commit to that branch. @ngoduykhanh I can't seem to replicate the checkbox issue on my side. When I check it, the browser does the javascript call and the checkbox stays checked after it succeeds. I'll keep trying to replicate but I'm probably missing something. Also, for your comment in the code the `DomainSetting.domain` is actually a reference to a `Domain` object (via a relationship in the model) instead of just the domain name. It's working for me but did your fix solve an issue?

kerem commented

Author

Owner

@trenb commented on GitHub (Jul 3, 2016):

@ivanfilippov I've got that, tested and working perfectly now. Thank you!

@trenb commented on GitHub (Jul 3, 2016): @ivanfilippov I've got that, tested and working perfectly now. Thank you!

kerem commented

Author

Owner

@ngoduykhanh commented on GitHub (Jul 3, 2016):

@ivanfilippov

Also, for your comment in the code the DomainSetting.domain is actually a reference to a Domain object (via a relationship in the model) instead of just the domain name. It's working for me but did your fix solve an issue?

I see. I've tried again. The exception which I got is:

    if bool(int(ondemand_creation.value)) == True:
ValueError: invalid literal for int() with base 10: 'true'

Looking to the DB I see:

powerdnsadmin2=# select * from domain_setting;
 id | domain_id |      setting      | value
----+-----------+-------------------+-------
  1 |         1 | create_via_dyndns | true
  2 |         2 | create_via_dyndns | true
(2 rows)

It means that ondemand_creation.value is a string with value true and cannot be parsed into integer. But why the value is true instead of 1 or 0 ? I realize that the new_value which the view get from the browser is True (bool type).

Depends on the DB backend, It is difference between MySQL and Postgresql

mysql> insert into domain_setting(domain_id, setting, value) values(1,'create_via_dyndns',True);
Query OK, 1 row affected (0.00 sec)

mysql> select * from domain_setting;
+----+-----------+-------------------+-------+
| id | domain_id | setting           | value |
+----+-----------+-------------------+-------+
|  1 |         1 | create_via_dyndns | 1     |
+----+-----------+-------------------+-------+
1 row in set (0.00 sec)

powerdnsadmin=# insert into domain_setting(domain_id, setting, value) values(1,'create_via_dyndns',True);
INSERT 0 1
powerdnsadmin=# select * from domain_setting;
 id | domain_id |      setting      | value
----+-----------+-------------------+-------
  1 |         1 | create_via_dyndns | true
(1 rows)

That's the reason why I got the exception :D. I think you better to set the value of settings in domain_setting to (True or False) instead of (1 or 0). Just likes what we did in the setting table

mysql> select * from setting;
+----+-------------------+-------+
| id | name              | value |
+----+-------------------+-------+
|  1 | maintenance       | False |
|  3 | fullscreen_layout | True  |
+----+-------------------+-------+
2 rows in set (0.00 sec)

@ngoduykhanh commented on GitHub (Jul 3, 2016): @ivanfilippov > Also, for your comment in the code the DomainSetting.domain is actually a reference to a Domain object (via a relationship in the model) instead of just the domain name. It's working for me but did your fix solve an issue? I see. I've tried again. The exception which I got is: ``` if bool(int(ondemand_creation.value)) == True: ValueError: invalid literal for int() with base 10: 'true' ``` Looking to the DB I see: ``` powerdnsadmin2=# select * from domain_setting; id | domain_id | setting | value ----+-----------+-------------------+------- 1 | 1 | create_via_dyndns | true 2 | 2 | create_via_dyndns | true (2 rows) ``` It means that `ondemand_creation.value` is a string with value `true` and cannot be parsed into integer. But why the value is `true` instead of `1` or `0` ? I realize that the [new_value](https://github.com/ivanfilippov/PowerDNS-Admin/commit/4eb5862ecbb0316f25a4a8c72f39f0c5bcd74f5b#diff-b5099d1f0106025f31781ccbe0a59d13R459) which the `view` get from the browser is `True` (bool type). Depends on the DB backend, It is difference between MySQL and Postgresql ``` mysql> insert into domain_setting(domain_id, setting, value) values(1,'create_via_dyndns',True); Query OK, 1 row affected (0.00 sec) mysql> select * from domain_setting; +----+-----------+-------------------+-------+ | id | domain_id | setting | value | +----+-----------+-------------------+-------+ | 1 | 1 | create_via_dyndns | 1 | +----+-----------+-------------------+-------+ 1 row in set (0.00 sec) ``` ``` powerdnsadmin=# insert into domain_setting(domain_id, setting, value) values(1,'create_via_dyndns',True); INSERT 0 1 powerdnsadmin=# select * from domain_setting; id | domain_id | setting | value ----+-----------+-------------------+------- 1 | 1 | create_via_dyndns | true (1 rows) ``` That's the reason why I got the exception :D. I think you better to set the value of settings in `domain_setting` to (`True` or `False`) instead of (`1` or `0`). Just likes what we did in the `setting` table ``` mysql> select * from setting; +----+-------------------+-------+ | id | name | value | +----+-------------------+-------+ | 1 | maintenance | False | | 3 | fullscreen_layout | True | +----+-------------------+-------+ 2 rows in set (0.00 sec) ```

kerem commented

Author

Owner

@ivanfilippov commented on GitHub (Jul 3, 2016):

Good call, I'm using MySQL, I'll make the change to put in True instead of
the integer.

Ivan Filippov
On Jul 2, 2016 21:33, "Khanh Ngo" notifications@github.com wrote:

@ivanfilippov https://github.com/ivanfilippov

Also, for your comment in the code the DomainSetting.domain is actually a
reference to a Domain object (via a relationship in the model) instead of
just the domain name. It's working for me but did your fix solve an issue?

I see. I've tried again. The exception which I got is:
if bool(int(ondemand_creation.value)) == True:
ValueError: invalid literal for int() with base 10: 'true'

Looking to the DB I see:

powerdnsadmin2=# select * from domain_setting;
id | domain_id | setting | value
----+-----------+-------------------+-------
1 | 1 | create_via_dyndns | true
2 | 2 | create_via_dyndns | true
(2 rows)

It means that ondemand_creation.value is a string with value true and
cannot be parsed into integer. But why the value is true instead of 1 or 0
? I realize that the new_value
github.com/ivanfilippov/PowerDNS-Admin@4eb5862ecb (diff-b5099d1f01)
which the view get from the browser is True (bool type).

Depends on the DB backend, It is difference between MySQL and Postgresql

mysql> insert into domain_setting(domain_id, setting, value) values(1,'create_via_dyndns',True);
Query OK, 1 row affected (0.00 sec)

mysql> select * from domain_setting;
+----+-----------+-------------------+-------+
| id | domain_id | setting | value |
+----+-----------+-------------------+-------+
| 1 | 1 | create_via_dyndns | 1 |
+----+-----------+-------------------+-------+
1 row in set (0.00 sec)

powerdnsadmin=# insert into domain_setting(domain_id, setting, value) values(1,'create_via_dyndns',True);
INSERT 0 1
powerdnsadmin=# select * from domain_setting;
id | domain_id | setting | value
----+-----------+-------------------+-------
1 | 1 | create_via_dyndns | true
(1 rows)

That's the reason why I got the exception :D. I think you better to set
the value of settings in domain_setting to (True or False) instead of (1
or 0). Just likes what we did in the setting table

mysql> select * from setting;
+----+-------------------+-------+
| id | name | value |
+----+-------------------+-------+
| 1 | maintenance | False |
| 3 | fullscreen_layout | True |
+----+-------------------+-------+
2 rows in set (0.00 sec)

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/ngoduykhanh/PowerDNS-Admin/issues/61#issuecomment-230133384,
or mute the thread
https://github.com/notifications/unsubscribe/AAT5bl0moK_XiuVMd5r88fSRw3jIMdh_ks5qRy1ugaJpZM4JDcmj
.

@ivanfilippov commented on GitHub (Jul 3, 2016): Good call, I'm using MySQL, I'll make the change to put in True instead of the integer. Ivan Filippov On Jul 2, 2016 21:33, "Khanh Ngo" notifications@github.com wrote: > @ivanfilippov https://github.com/ivanfilippov > > Also, for your comment in the code the DomainSetting.domain is actually a > reference to a Domain object (via a relationship in the model) instead of > just the domain name. It's working for me but did your fix solve an issue? > > I see. I've tried again. The exception which I got is: > > ``` > if bool(int(ondemand_creation.value)) == True: > ``` > > ValueError: invalid literal for int() with base 10: 'true' > > Looking to the DB I see: > > powerdnsadmin2=# select \* from domain_setting; > id | domain_id | setting | value > ----+-----------+-------------------+------- > 1 | 1 | create_via_dyndns | true > 2 | 2 | create_via_dyndns | true > (2 rows) > > It means that ondemand_creation.value is a string with value true and > cannot be parsed into integer. But why the value is true instead of 1 or 0 > ? I realize that the new_value > https://github.com/ivanfilippov/PowerDNS-Admin/commit/4eb5862ecbb0316f25a4a8c72f39f0c5bcd74f5b#diff-b5099d1f0106025f31781ccbe0a59d13R459 > which the view get from the browser is True (bool type). > > Depends on the DB backend, It is difference between MySQL and Postgresql > > mysql> insert into domain_setting(domain_id, setting, value) values(1,'create_via_dyndns',True); > Query OK, 1 row affected (0.00 sec) > > mysql> select \* from domain_setting; > +----+-----------+-------------------+-------+ > | id | domain_id | setting | value | > +----+-----------+-------------------+-------+ > | 1 | 1 | create_via_dyndns | 1 | > +----+-----------+-------------------+-------+ > 1 row in set (0.00 sec) > > powerdnsadmin=# insert into domain_setting(domain_id, setting, value) values(1,'create_via_dyndns',True); > INSERT 0 1 > powerdnsadmin=# select \* from domain_setting; > id | domain_id | setting | value > ----+-----------+-------------------+------- > 1 | 1 | create_via_dyndns | true > (1 rows) > > That's the reason why I got the exception :D. I think you better to set > the value of settings in domain_setting to (True or False) instead of (1 > or 0). Just likes what we did in the setting table > > mysql> select \* from setting; > +----+-------------------+-------+ > | id | name | value | > +----+-------------------+-------+ > | 1 | maintenance | False | > | 3 | fullscreen_layout | True | > +----+-------------------+-------+ > 2 rows in set (0.00 sec) > > — > You are receiving this because you were mentioned. > Reply to this email directly, view it on GitHub > https://github.com/ngoduykhanh/PowerDNS-Admin/issues/61#issuecomment-230133384, > or mute the thread > https://github.com/notifications/unsubscribe/AAT5bl0moK_XiuVMd5r88fSRw3jIMdh_ks5qRy1ugaJpZM4JDcmj > .

kerem commented

Author

Owner

@ivanfilippov commented on GitHub (Jul 3, 2016):

I think I've got it, check this commit github.com/ivanfilippov/PowerDNS-Admin@b096788cf1

It now stores the string representation of True and False and still works fine in MySQL. @ngoduykhanh can you try with pgSQL (I don't have a pgSQL environment ready)?

@ivanfilippov commented on GitHub (Jul 3, 2016): I think I've got it, check this commit https://github.com/ivanfilippov/PowerDNS-Admin/commit/b096788cf1e3ef24801b43819d23e28ad6708090 It now stores the string representation of `True` and `False` and still works fine in MySQL. @ngoduykhanh can you try with pgSQL (I don't have a pgSQL environment ready)?

kerem commented

Author

Owner

@ngoduykhanh commented on GitHub (Jul 3, 2016):

I have test with my Postgresql env, it works fine if the setting is preset. Just 2 more small adjustment need to be done. I've commented in your code. Thanks @ivanfilippov

@ngoduykhanh commented on GitHub (Jul 3, 2016): I have test with my Postgresql env, it works fine if the setting is preset. Just 2 more small adjustment need to be done. I've commented in your code. Thanks @ivanfilippov

kerem commented

Author

Owner

@ivanfilippov commented on GitHub (Jul 3, 2016):

Thanks for the comments! Try github.com/ivanfilippov/PowerDNS-Admin@e0461a5210 and let me know what you think.

@ivanfilippov commented on GitHub (Jul 3, 2016): Thanks for the comments! Try https://github.com/ivanfilippov/PowerDNS-Admin/commit/e0461a52107d30c6121a09f7e83b46ca5db73fba and let me know what you think.

kerem commented

Author

Owner

@ngoduykhanh commented on GitHub (Jul 4, 2016):

It looks like you missed one of my comments. The last one is about the checkbox's value after changing from integers to True/False string. See comment. I think you can create the PR after that. Thanks.

@ngoduykhanh commented on GitHub (Jul 4, 2016): It looks like you missed one of my comments. The last one is about the checkbox's value after changing from integers to True/False string. See [comment](https://github.com/ivanfilippov/PowerDNS-Admin/commit/4eb5862ecbb0316f25a4a8c72f39f0c5bcd74f5b#commitcomment-18106753). I think you can create the PR after that. Thanks.

kerem commented

Author

Owner

@ivanfilippov commented on GitHub (Jul 6, 2016):

Fixed and PR submitted.

Thanks for all your help @ngoduykhanh 😄

@ivanfilippov commented on GitHub (Jul 6, 2016): Fixed and PR submitted. Thanks for all your help @ngoduykhanh :smile:

kerem commented

Author

Owner

@ngoduykhanh commented on GitHub (Jul 6, 2016):

Merged. Thanks @ivanfilippov

@ngoduykhanh commented on GitHub (Jul 6, 2016): Merged. Thanks @ivanfilippov

kerem commented

Author

Owner

@joachimtingvold commented on GitHub (Jul 6, 2016):

create_db.py needs an update for this too? On a general note; how to address database changes for existing users? db_upgrade.py only handles the actually upgrade of version/whatnot, and does not address new/updates schemas?

@joachimtingvold commented on GitHub (Jul 6, 2016): create_db.py needs an update for this too? On a general note; how to address database changes for existing users? db_upgrade.py only handles the actually upgrade of version/whatnot, and does not address new/updates schemas?

kerem commented

Author

Owner

@joachimtingvold commented on GitHub (Jul 6, 2016):

Would be nice to add some CREATE TABLE stuff for this change as well, so we don't have to reverse-engineer what types of columns/whatnot (-:

@joachimtingvold commented on GitHub (Jul 6, 2016): Would be nice to add some `CREATE TABLE` stuff for this change as well, so we don't have to reverse-engineer what types of columns/whatnot (-:

kerem commented

Author

Owner

@joachimtingvold commented on GitHub (Jul 6, 2016):

And yes, the above commit/merge broke the Admin-page for those of us without the table (-:

[Wed Jul 06 16:25:26.795965 2016] [wsgi:error] [pid 18900] ProgrammingError: (psycopg2.ProgrammingError) relation "domain_setting" does not exist
[Wed Jul 06 16:25:26.795985 2016] [wsgi:error] [pid 18900] LINE 2: FROM domain_setting 
[Wed Jul 06 16:25:26.796005 2016] [wsgi:error] [pid 18900]              ^
[Wed Jul 06 16:25:26.796044 2016] [wsgi:error] [pid 18900]  [SQL: 'SELECT domain_setting.id AS domain_setting_id, domain_setting.domain_id AS domain_setting_domain_id, domain_setting.setting AS domain_setting_setting, domain_setting.value AS domain_setting_value \\nFROM domain_setting \\nWHERE %(param_1)s = domain_setting.domain_id'] [parameters: {'param_1': 4}]

@joachimtingvold commented on GitHub (Jul 6, 2016): And yes, the above commit/merge broke the Admin-page for those of us without the table (-: ``` [Wed Jul 06 16:25:26.795965 2016] [wsgi:error] [pid 18900] ProgrammingError: (psycopg2.ProgrammingError) relation "domain_setting" does not exist [Wed Jul 06 16:25:26.795985 2016] [wsgi:error] [pid 18900] LINE 2: FROM domain_setting [Wed Jul 06 16:25:26.796005 2016] [wsgi:error] [pid 18900] ^ [Wed Jul 06 16:25:26.796044 2016] [wsgi:error] [pid 18900] [SQL: 'SELECT domain_setting.id AS domain_setting_id, domain_setting.domain_id AS domain_setting_domain_id, domain_setting.setting AS domain_setting_setting, domain_setting.value AS domain_setting_value \\nFROM domain_setting \\nWHERE %(param_1)s = domain_setting.domain_id'] [parameters: {'param_1': 4}] ```

kerem commented

Author

Owner

@joachimtingvold commented on GitHub (Jul 13, 2016):

@ivanfilippov, could you provide the CREATE TABLE for this one?

@joachimtingvold commented on GitHub (Jul 13, 2016): @ivanfilippov, could you provide the `CREATE TABLE` for this one?

kerem commented

Author

Owner

@joachimtingvold commented on GitHub (Jul 13, 2016):

I guess roughly something like this;

CREATE SEQUENCE domain_setting_id_seq START 1;

CREATE TABLE "domain_setting" (
    "id" integer NOT NULL DEFAULT nextval('domain_setting_id_seq'::regclass),
    "domain_id" integer NOT NULL,
    "setting" character varying(64),
    "value" character varying(256),
    CONSTRAINT "domain_setting_pkey" PRIMARY KEY (id)
) WITHOUT OIDS;

@joachimtingvold commented on GitHub (Jul 13, 2016): I guess roughly something like this; ``` CREATE SEQUENCE domain_setting_id_seq START 1; CREATE TABLE "domain_setting" ( "id" integer NOT NULL DEFAULT nextval('domain_setting_id_seq'::regclass), "domain_id" integer NOT NULL, "setting" character varying(64), "value" character varying(256), CONSTRAINT "domain_setting_pkey" PRIMARY KEY (id) ) WITHOUT OIDS; ```

kerem commented

Author

Owner

@ivanfilippov commented on GitHub (Jul 13, 2016):

@jallakim You can use db_migrate.py to generate the code that reflects the schema changes that happen between versions (they get put into the db_repository directory) and db_upgrade.py to apply the changes . You can run both every time you upgrade your PDNS-Admin repo to keep up to date, that won't break anything.

create_db.py shouldn't need to get upgraded because it's meant to to be used during a new install and it will create the database based on the current models defined in models.py 😄

Sorry for the delay in response, we don't get notified about comments on closed issues and I only saw your recent comments because you mentioned my username directly.

Here is the schema that is currently in my database (I'm using MariaDB, MySQL should be identical, will need some modifications for SQLite and PGsql):

CREATE TABLE `domain_setting` (
 `id` int(11) NOT NULL AUTO_INCREMENT,
 `setting` varchar(255) NOT NULL,
 `value` varchar(255) DEFAULT NULL,
 `domain_id` int(11) DEFAULT NOT NULL,
 PRIMARY KEY (`id`)
) ENGINE=InnoDB AUTO_INCREMENT=3 DEFAULT CHARSET=latin1

@ivanfilippov commented on GitHub (Jul 13, 2016): @jallakim You can use `db_migrate.py` to generate the code that reflects the schema changes that happen between versions (they get put into the db_repository directory) and `db_upgrade.py` to apply the changes . You can run both every time you upgrade your PDNS-Admin repo to keep up to date, that won't break anything. `create_db.py` shouldn't need to get upgraded because it's meant to to be used during a new install and it will create the database based on the current models defined in `models.py` :smile: Sorry for the delay in response, we don't get notified about comments on closed issues and I only saw your recent comments because you mentioned my username directly. Here is the schema that is currently in my database (I'm using MariaDB, MySQL should be identical, will need some modifications for SQLite and PGsql): ``` sql CREATE TABLE `domain_setting` ( `id` int(11) NOT NULL AUTO_INCREMENT, `setting` varchar(255) NOT NULL, `value` varchar(255) DEFAULT NULL, `domain_id` int(11) DEFAULT NOT NULL, PRIMARY KEY (`id`) ) ENGINE=InnoDB AUTO_INCREMENT=3 DEFAULT CHARSET=latin1 ```

kerem commented

Author

Owner

@ngoduykhanh commented on GitHub (Jul 13, 2016):

Actually now we can re-run create_db.py script to create missing tables.

@ngoduykhanh commented on GitHub (Jul 13, 2016): Actually now we can re-run `create_db.py` script to create missing tables.

kerem commented

Author

Owner

@ivanfilippov commented on GitHub (Jul 13, 2016):

Oh cool, I didn't know that. So running create_db.py after we change the models will do the same thing as doing a db_migrate.py and db_upgrade.py?

@ivanfilippov commented on GitHub (Jul 13, 2016): Oh cool, I didn't know that. So running `create_db.py` after we change the models will do the same thing as doing a `db_migrate.py` and `db_upgrade.py`?

kerem commented

Author

Owner

@joachimtingvold commented on GitHub (Jul 13, 2016):

I still can't see how the domain_setting table would be created for new installs as it is now? You'd need to edit create_db.py as a minimum? It currently only handles the Role and Setting classes from models.py, and your PR didn't change that file at all.

@joachimtingvold commented on GitHub (Jul 13, 2016): I still can't see how the `domain_setting` table would be created for new installs as it is now? You'd need to edit `create_db.py` as a minimum? It currently only handles the `Role` and `Setting` classes from `models.py`, and your PR didn't change that file at all.

kerem commented

Author

Owner

@joachimtingvold commented on GitHub (Jul 13, 2016):

Hmm, never mind. I guess the init-thingie is just for tables that needs initial values, which is not the case for the domain_setting.

@joachimtingvold commented on GitHub (Jul 13, 2016): Hmm, never mind. I guess the init-thingie is just for tables that needs initial values, which is not the case for the `domain_setting`.

kerem commented