Hi Ivanov:

In message <99ecbcba791279a9ae9a3438a3417e90@riseup.net>,
Ivanov writes:
>> You don't need to migrate if you haven't run initialization. 
>
>I just tried a few options to make sure none of them worked :3

Got it.

>> What happens if you do this:
>> 
>>   start with an installed and configured (in config.ini) tracker and
>>   an empty database (as above).
>> 
>>   run 'roundup-admin -i tracker-home list user' 
>> 
>> I think this should create all the tables but not create any rows in
>> the tables.
>
>Yes, it creates tables as expected. But what's the difference with
>performing a migration?

You don't load initial_data.py with a migration.

>> I'm not sure if you can use roundup-admin to create the admin and
>> anonymous users manually (because the admin user in the db isn't
>> defined). However you can use psql to set the admin id=1,
>> username=admin and roles=Admin. Then once that is present for the
>> admin user, you can set the admin password using roundup-admin, create
>> the anonymous user etc.
>
>Hmm... If I run this command after the migration is done:
>
>  roundup-admin create user username="admin" roles="Admin"
>
>it creates 'admin' user with id 1.

Ah good. I know Roundup has a fallback for id 1 that bypasses
permissions. At the moment, roundup-admin always operates as id
1. (This is something to fix:
https://issues.roundup-tracker.org/issue2551246.)

>> I would have to check but I think a change to create an:
>> 
>>   init --nocreatedb
>> 
>> that just loads initial_data.py would be relatively
>> easy. Alternatively we can add a 'pragma nocreatedb=true'. (We can
>> create a new ticket for this).
>
>Both look interesting. As I understand it, pragmas are permanent
>settings for Roundup admin commands. Is it correct?

Rather than permanent, I would say sticky for a session. roundup-admin
can be used from the command line or interactively. Pragmas only last
for one invocation of roundup-admin. But once set continue to apply for
all commands during the session/invocation until changed.

With the development code, you can use:

  -P pragma=value   -- Set a pragma on command line rather than interactively.
                       Can be used multiple times.

on the command line. This was added after 2.3.0 was released and will
be part of 2.4.0. Interactively you can use 'pragma setting=value'
(which is available in 2.3.0) and it will persist until you exit the
roundup-admin interactive session.

>On the one hand, it
>is better to be able to permanently disable database creation. On the
>other hand, the ability to temporarily disable this feature may also be
>important, and in my case I could just as easily use a flag.

I don't like to build too much magic into the code. What do you think
of Roundup trying to nuke() the db. If it finds that the db exists but
fails to delete it because of missing permissions it skips the
delete/create and continues with the rest of the schema setup, data
load etc.

The delete error raises psycopg2.errors.InsufficientPrivilege. I don't
need to parse the exception args/message. One problem is what happens
if the db isn't empty. I think it will fail trying to create
tables. So the data will be ok but the error message will point to a
table creation issue and not an inability to drop/create the db.

It is possible to have other tables in the Roundup db and work with
them from Roundup using psycodb2 (via the db connection parameter)
directly. Roundup shouldn't touch those tables. I suppose using the
schema table we could figure out what tables should exist, but indexes
and other things would be left around. So actively trying to drop
tables to clean the db doesn't seem like a good idea.

>I think it would also be useful to have an option to read admin's
>password from a file. This will avoid calling the shell to execute the
>command using CI. But I don't want to ask for too much.

It doesn't bypass the need for a shell as it involves shell
redirection/piping but:

the paragraph before this section:

   https://roundup-tracker.org/docs/admin_guide.html#using-with-the-shell

and

   https://issues.roundup-tracker.org/issue2550789

If you can hook up stdin without a shell it should work. Also this
prevents the password from possibly being exposed by ps.

>I think we could close this issue since Roundup can now work with
>postgresql services and also supports the non-public schemas. There is
>still an issue with getting database/schema names when there is no
>successful connection. But it seems that we can't solve this now. 

I'm not sure I would say 'supports the non-public schemas'. It no
longer actively interferes with non-public schemas 8-). Support would
look like issue2550852.

>Since the database creation bypass is not specific to postgresql, I
>think it would be better to create a new issue.

Agreed, it is shared by mysql and postgresql (and other server based
db's like oracle, mongodb....). SQLite and anydbm don't have the
equivalent of createdb permission.