Stubbed out architecture for inter-user notification system.

Review Request #5909 — Created May 31, 2014 and discarded

Information

Review Board
master
1450a1a...

Reviewers

Stubbed out architecture for inter-user notification system. [WIP]

No testing was done because no functioning code was written.. When the architect is approved, tests cases along with functioning code will be submitted.

Description From Last Updated

Col: 1 E302 expected 2 blank lines, found 1

reviewbotreviewbot

Managers are special classes that manage models. This doesn't look like a manager. Instead, it looks like it's a container …

chipx86chipx86

This would be a Model. I would just call it "Notification".

chipx86chipx86

General comments on docstrings: They must always be in one of the following forms: """One-line summary.""" or: """One-line summary. Multi-line …

chipx86chipx86

You should instead use help_text (if you want this user-visible), or use: #: blah blah for defining comments on a …

chipx86chipx86

"sender" and "recipient" are probably better terms to use. Make sure you use related_name= on these, or you'll have collisions. …

chipx86chipx86

Col: 58 W291 trailing whitespace

reviewbotreviewbot

I think a BooleanField would be sufficient. "read" or "new" or something. It'll take less space, is faster to index …

chipx86chipx86

This is state in the database that can be queried. There shouldn't be any state locally here.

chipx86chipx86

You'll almost never have an __init__ for models. You should have defaults set on fields instead.

chipx86chipx86

undefined name 'this'

reviewbotreviewbot

undefined name 'this'

reviewbotreviewbot

undefined name 'this'

reviewbotreviewbot

I'm not sure why this is separate from the stuff above? Or why it's a nested class?

chipx86chipx86

Col: 1 W391 blank line at end of file

reviewbotreviewbot
reviewbot
  1. This is a review from Review Bot.
      Tool: PEP8 Style Checker
      Processed Files:
        reviewboard/accounts/models.py
      Ignored Files:
    
    
  2. reviewboard/accounts/models.py (Diff revision 1)
     
     
    Show all issues
    Col: 1
     E302 expected 2 blank lines, found 1
    
  3. reviewboard/accounts/models.py (Diff revision 1)
     
     
    Show all issues
    Col: 58
     W291 trailing whitespace
    
  4. reviewboard/accounts/models.py (Diff revision 1)
     
     
    Show all issues
    Col: 1
     W391 blank line at end of file
    
  5. 
      
reviewbot
  1. This is a review from Review Bot.
      Tool: Pyflakes
      Processed Files:
        reviewboard/accounts/models.py
      Ignored Files:
    
    
  2. reviewboard/accounts/models.py (Diff revision 1)
     
     
    Show all issues
     undefined name 'this'
    
  3. reviewboard/accounts/models.py (Diff revision 1)
     
     
    Show all issues
     undefined name 'this'
    
  4. reviewboard/accounts/models.py (Diff revision 1)
     
     
    Show all issues
     undefined name 'this'
    
  5. 
      
chipx86
  1. 
      
  2. reviewboard/accounts/models.py (Diff revision 1)
     
     
    Show all issues

    Managers are special classes that manage models. This doesn't look like a manager. Instead, it looks like it's a container for other classes.

    I think we should use "Notification" terminology, and move all this to the notifications/ directory. Managers live in managers.py files, and models live in models.py files.

  3. reviewboard/accounts/models.py (Diff revision 1)
     
     
    Show all issues

    This would be a Model.

    I would just call it "Notification".

  4. reviewboard/accounts/models.py (Diff revision 1)
     
     
     
     
     
     
     
     
     
    Show all issues

    General comments on docstrings:

    They must always be in one of the following forms:

    """One-line summary."""
    

    or:

    """One-line summary.
    
    Multi-line description.
    """
    

    No line can exceed 79 characters.

  5. reviewboard/accounts/models.py (Diff revision 1)
     
     
    Show all issues

    You should instead use help_text (if you want this user-visible), or use:

    #: blah blah
    

    for defining comments on a field. (This will then be represented in any codebase docs we generate.)

  6. reviewboard/accounts/models.py (Diff revision 1)
     
     
     
     
     
    Show all issues

    "sender" and "recipient" are probably better terms to use.

    Make sure you use related_name= on these, or you'll have collisions. Names like "sent_notifications" and "received_notifications".

  7. reviewboard/accounts/models.py (Diff revision 1)
     
     
    Show all issues

    I think a BooleanField would be sufficient. "read" or "new" or something. It'll take less space, is faster to index on, and I don't think we need anything more complex.

    If we do need states, then we should just have flags for the different states, and store a 1-byte CharField for them. See what we do in ReviewRequest for 'status'.

  8. reviewboard/accounts/models.py (Diff revision 1)
     
     
    Show all issues

    This is state in the database that can be queried. There shouldn't be any state locally here.

  9. reviewboard/accounts/models.py (Diff revision 1)
     
     
    Show all issues

    You'll almost never have an __init__ for models. You should have defaults set on fields instead.

  10. reviewboard/accounts/models.py (Diff revision 1)
     
     
    Show all issues

    I'm not sure why this is separate from the stuff above? Or why it's a nested class?

  11. 
      
PE
Review request changed
Status:
Discarded