[pkg-apparmor] UDD notifications script

u u at 451f.org
Mon Feb 23 11:35:34 UTC 2015


Hi,

Christian Boltz:
> may I also offer some "nice to have" comments? ;-)

Indeed, thanks a lot!

> Am Donnerstag, 19. Februar 2015 schrieb intrigeri:
[..]
> so maybe (untested!)
>     buglist = cursor.fetchall()
> could work

it does!

>> * When using the get_bug_list output (a list of pairs) in
>>   send_team_notification, we have to access it by indices: bug[0] to
>>   get the bug ID, bug[1] to get the added or removed usertag. It's not
>> astonishingly obvious. I would recommend that get_bug_list outputs:
>>
>>   - either a list of dictionaries so we can then write bug['id']
>>     and bug['usertag']
> 
> I didn't see an obvious way to do this in the psycopg docu, so if we 
> really want this, you'll probably need something like
>     buglist2 = []
>     for bug in buglist:
>         buglist2.append( { 'id': bug[0], 'usertag': bug[1] })
> which is not worth the effort IMHO.
> 
> Either keep the numbers, or define constands like
>     field_id = 0
>     field_usertag = 1
> that you can use instead (define those constants inside each function 
> to avoid conflicting field numbers for another function/query!)

In the end I did that the way intrigeri suggested, but your suggestion
seemed quite straight forward too.

>>   - or a dictionary whose keys would be the bug IDs, and values would
>>     be the usertag; but wait! this would be too limiting, read on:
> 
> Indeed - what happens if a bug has multiple usertags?

If a bug has multiple tags, each one will be a list item, so we can
compare if this one list item already exists.

>> * I see we first retrieve a list of usertagged bugs (in get_bug_list),
>> and then run one more query per bug that had a usertag added or
>> removed, in order to get its title. Alternatively, get_bug_list could
>> use a JOIN to retrieve all the data we need about all usertagged bugs
>> in one go. No idea the higher number of queries (current
>> implementation) costs more than retrieving the title of bugs that we
>> won't use (suggested implementation). 

[..]
> In this case, the question is how many bug ids and tags the first query 
> returns, and for how many of them you need to look up the bug title.
> 
> Anyway, you can speed it up by replacing multiple calls of
>     SELECT title from bugs WHERE id='1'
>     SELECT title from bugs WHERE id='2'
>     SELECT title from bugs WHERE id='3'
> with one call of
>     SELECT id, title from bugs WHERE id IN ('1', '2', '3')
> 
> Note that I included the id in the query to avoid ordering problems.
> 
> Also note that this is the first thing to fix/change if you notice 
> performance problems ;-)

Ok.

> 
> BTW: did I ever point you to my "1001 bugs - or: the golden rules of 
> bad programming" slides? ;-)
> 
> English version:
>     http://blog.cboltz.de/archives/63-1001-bugs-or-the-golden-rules-of-bad-programming.html
> German version:
>     http://blog.cboltz.de/archives/64-1001-Bugs-oder-die-goldenen-Regeln-fuer-schlechte-Programmierung.html
> 
[..]

>> Anyhow, putting aside
>> performance and resources considerations, I would find the
>> implementation of send_team_notification more readable and elegant if
>> get_bug_list returned a list of dictionaries, each such dictionary
>> having keys (id, title, usertag). Food for thought :)
> 
> Can there be multiple usertags on a bug?

yes. And each will produce an own list item.

[...]

> In general I agree, however in this case it would be the only line after 
> the except block, so the current code is probably easier to understand.

Ok. I agree about the readability. Still, in the end I put the return on
the bottom of the function so it would be like for the other functions
in this script which have a similar structure.

> The perfect solution would be:
> 
> def read_statefile(state_filename):
>     statefile_content = ''
>     try:
>         ...
>     except ...:
>         ...
> 
>     return statefile_content
> 
> 
> Final note: I wrote this mail without actually testing anything. 
> Also, I only looked at the parts listed in this mail, not the whole script.

Perfect, it helped me a lot! And it's always great to have 2 points of view.

Cheers
u.




More information about the pkg-apparmor-team mailing list