launchpad-dev team mailing list archive

[Robert Collins <robert.collins@xxxxxxxxxxxxx>]

This was a really interesting thread, and I'm glad I started it.

The persistence layer project I'm kicking off -
https://dev.launchpad.net/LEP/PersistenceLayer - may not go as far as
I proposed at the start of this thread.

Still, I want to address some of the concerns expressed in the thread
though, specifically about redundant class definitions.

I think we will end up with redundancy in our definitions, but it
won't be valueless. On a related note I'd like to nuke the interfaces
that don't carry their own weight, and will certainly not be adding
noddy interfaces in the persistence layer itself.

The reason I think we'll end up with some redundancy is because by
having a separated layer, we either have extremely structureless
things - e.g. a single subclass of object with implementsInterface()
called on it and attributes set, or roughly one class per conceptual
thing we bring back from the tables. I think the latter is better
because it does permit writing object centric code when we think that
that makes sense. Having the option is nice.

As a for instance, I'd expect something like:
class Entity:
class Person(Entity):
class Team(Entity):

in the business layer

class Person(SQLBase):
...
and class PersonMapper(Mapper):

in the db layer.
(And for testing a TestPersonMapper, which is in-memory).

The most important things though, of all of this, are twofold:
 - we should be able to tell when code is business or storage.
 - we should assume single-object manipulating query/update code is
faulty. *thats* something we can assume now, but it will take a lot of
effort to change things, so I'm not going to vigorously push on this
meme until we've got the persistence layer well underway.

-Rob