Launchpad itself

Merge lp://staging/~rockstar/launchpad/sourcepackagerecipe-name-contstraint into lp://staging/launchpad

sourcepackagerecipe-name-contstraint
Merge into devel

Proposed by Paul Hummer on 2010-05-27

Status:

Rejected

Rejected by:

Paul Hummer on 2010-05-28

Proposed branch:

lp://staging/~rockstar/launchpad/sourcepackagerecipe-name-contstraint

Merge into:

lp://staging/launchpad

Diff against target:

176 lines (+79/-7)

4 files modified

lib/lp/code/errors.py (+5/-0)
lib/lp/code/model/sourcepackagerecipe.py (+36/-4)
lib/lp/code/model/tests/test_sourcepackagerecipe.py (+35/-0)
lib/lp/registry/model/person.py (+3/-3)

To merge this branch:

bzr merge lp://staging/~rockstar/launchpad/sourcepackagerecipe-name-contstraint

High

Fix Released

Link a bug report

Reviewer	Review Type	Date Requested	Status
Stuart Bishop (community)		2010-05-27	Disapprove on 2010-05-27
Review via email: mp+26122@code.staging.launchpad.net

Description of the change

This branch ensures that a person cannot own two recipes owned by the same person. There's a db patch for this as well, but Aaron and I have decided that we also need to enforce this in the model. The followup to this branch is making sure this is dealt with in the UI, but we need to get this branch landed soon to make sure edge is prevented from having this problem.

Revision history for this message

Stuart Bishop (stub) wrote on 2010-05-27:

UI code should ensure that invalid values are never passed through, as that will generate an OOPS.

Database constraints exist to catch things that slip through and generate the OOPS.

Guards at this level are unnecessary and wasteful, just duplicating the functionality of the db constraint.

review: Disapprove

Revision history for this message

Robert Collins (lifeless) wrote on 2010-05-27:

On Thu, May 27, 2010 at 6:24 PM, Stuart Bishop
<email address hidden> wrote:
> Review: Disapprove
> UI code should ensure that invalid values are never passed through, as that will generate an OOPS.
>
> Database constraints exist to catch things that slip through and generate the OOPS.
>
> Guards at this level are unnecessary and wasteful, just duplicating the functionality of the db constraint.

What level do LP APIs operate at? I thought they spoke directly to the
model code, and we certainly don't want mistaken LP API calls to
generate a server side OOPS due to DB constraint violation.

Revision history for this message

Stuart Bishop (stub) wrote on 2010-05-27:

On Thu, May 27, 2010 at 2:54 PM, Robert Collins
<email address hidden> wrote:
> On Thu, May 27, 2010 at 6:24 PM, Stuart Bishop
> <email address hidden> wrote:
>> Review: Disapprove
>> UI code should ensure that invalid values are never passed through, as that will generate an OOPS.
>>
>> Database constraints exist to catch things that slip through and generate the OOPS.
>>
>> Guards at this level are unnecessary and wasteful, just duplicating the functionality of the db constraint.
>
> What level do LP APIs operate at? I thought they spoke directly to the
> model code, and we certainly don't want mistaken LP API calls to
> generate a server side OOPS due to DB constraint violation.

That might be a point. I'm not sure. How do we currently handle all
the other unique fields?

--
Stuart Bishop <email address hidden>
http://www.stuartbishop.net/