A Real Abstract BaseDatabaseWrapper Class

[mtrier]

I'd like to propose that we fix up the abstract BaseDatabaseWrapper
class so that it actually has all the hooks it needs. Right now the
two missing items I'm seeing are the absence of validation and
introspection. There is the expectation that the implementations will
have these and implement them appropriately (unless I overlooked
something).

It could just be a matter of stubbing them out in the __init__, such
as:

self.validation = BaseDatabaseValidation()

Thoughts?

Michael Trier
http://blog.michaeltrier.com/

[Malcolm Tredinnick]

Why? If your reason is self-documenting code for somebody implementing
an external backend, we can probably work something out.

If the reason is because it will somehow save time in subclasses, that's
a bad approach because backends are almost always going to need to
subclass the various classes and they should initialise attributes with
the right instances.

The engineering with putting "example" implementation code in __init__
is that there's going to be a very strong instinct (and many
code-checker tools will warn if you don't) to call super(...).__init__
and that would be a mistake in this case.

I think the first goal -- making it easy for people to write external
backends -- is a good one. We should make that as easy as possible and
code usually speaks louder than rewriting the code in English calling it
documentation at that level. But the good practices problem is an issue
here. We can work something out there if that's the motivation behind
your request. If there's some other reason, write some more.

Regards,
Malcolm

[mtrier]

Malcolm,

Thanks for the nice reply.

On Sep 11, 2:08 pm, Malcolm Tredinnick <malc...@pointy-stick.com>
wrote:

> Why? If your reason is self-documenting code for somebody implementing
> an external backend, we can probably work something out.

Let me be more concrete then. I went to implement a backend. Since
all backends inherit from BaseDatabaseWrapper I did that. I figured
at that point I would override / implement just the pieces that I
needed to. Since the BaseDatabaseValidation is fine (I don't care
about it) I didn't bother with it. But external code is just assuming
that I will have a variable called validation that points to a class /
subclass of BaseDatabaseValidation. Since I didn't I got errors.

Since the dummy backend (not the one I created but the real one in
Django) has these hooks I thought about inheriting from there, but
when looking at the other backends none do so that's probably not the
right way to go.

So I guess in short that's why I thought those things should be wired
up. Either way it's not going to make a difference to me, I just
thought it would tighten things up a bit.

Thanks,

Michael

[Malcolm Tredinnick]

On Thu, 2008-09-11 at 13:17 -0700, mtrier wrote:
> Malcolm,
>
> Thanks for the nice reply.
>
> On Sep 11, 2:08 pm, Malcolm Tredinnick <malc...@pointy-stick.com>
> wrote:
> > Why? If your reason is self-documenting code for somebody implementing
> > an external backend, we can probably work something out.
>
> Let me be more concrete then. I went to implement a backend. Since
> all backends inherit from BaseDatabaseWrapper I did that. I figured
> at that point I would override / implement just the pieces that I
> needed to. Since the BaseDatabaseValidation is fine (I don't care
> about it) I didn't bother with it. But external code is just assuming
> that I will have a variable called validation that points to a class /
> subclass of BaseDatabaseValidation. Since I didn't I got errors.

Yeah, okay. So validation is kind of the exception there. We should try
to work out a way to make this easier, you're right.

Can you open a ticket so that we don't forget this? It should be pretty
low-pain, modulo being careful not to set people up for a fall, and
certainly can't hurt things (and will help).

Regards,
Malcolm

[Kevin Teague]

On Sep 11, 8:15 am, mtrier <mtr...@gmail.com> wrote:
> I'd like to propose that we fix up the abstract BaseDatabaseWrapper
> class so that it actually has all the hooks it needs.

To be slightly pedantic, if all the methods in a class contain an
implementation, it's not an abstract base class, but simply a base
class. Abstract means interface - that is the method signature only
(method name, parameters and doc string), the method body is the
implementation (whether it's intended as a complete, partial or
example implementation does not matter). So "real abstract" is a bit
of an oxymoron, since real describes the implementation and abstract
describes the interface.