DatabaseClassSet.get should return None when id not present

[Michael Hudson-Doyle]

I've found at least 4 patterns for what the common SomeDatabaseObjectSet.get(id) methods do when the 'id' is not present:

1. nothing special, and thus raise SQLObjectNotFoundError. This doesn't seem that great an idea, though it's probably ok for methods that never expect to be called for a missing id (the id is never derived from user input, for example).

2. catch SQLObjectNotFoundError and reraise the launchpad specific NotFoundError.

3. return None.

4. ape the dictionary .get() method and return an optional second argument that defaults to None.

This seems a bit of a mess.

While 4 seems the most flexible, I think it's actually wasted effort: if you're after the database row with a particular id, it seems very unlikely that some other (non-None) object will do, and in my grepping I found exactly no code taking advantage of the flexibility of these methods (not even tests). Option 1 has clear disadvantages (exposing implementation details) and so the choice is between 2 and 3.

Steve asked for 3.

[Steve Alexander (stevea)]

We should be returning None.

This makes the code that typically uses these methods simpler, for example web application navigation code.

[Jeroen T. Vermeulen (jtv)]

SteveA and Kiko suggest a base class ContentObjectSet and interface IContentObjectSet with a consistent interface for common functionality.

Some of the *Set classes allow you to retrieve objects by name, others by id, some both, some by yet other attributes. As a first phase we will make this more explicit by replacing get() with getByName(), getById() etc. (Perhaps a getBy() that takes the identifying attribute as an argument?) We'll also get rid of __getitem__ to avoid conflicts between different classes' expectations.

We could also have a single get() that figures out the right type of search based on the type of its argument, but that may be ambiguous or hide mistakes.