launchpad-dev team mailing list archive

[Danilo Šegan <danilo@xxxxxxxxxxxxx>]

Hi Ian, welcome to the team :)

I agree that it would be nice if our "business logic" was split from
basic database access layer.  However, for all intents and purposes, I
want to vouch against "more ORM-like" approach (mostly because Storm
does allow us to get the best out of the database, and I am talking as
someone who has seen that querying on "something" or "something IS TRUE"
in Postgres doesn't hit the same indexes).

And not the least, object mapping can not express relational concepts
that SQL (and Storm) can.  When it comes to nailing down that last bit
of performance problem, we'll have to resort to it anyway (or we'll
create an ORM layer that will basically be as complex and expressive as
Storm, when the question pops up: why bother?).

У пет, 27. 08 2010. у 07:48 +1200, Robert Collins пише:

> ... interface conformance testing ...

This is something I found missing from the discussion here: interfaces.

Compared to Java and Hibernate approach, we do have interfaces which are
definitions of how an object would look like.  And we do have both
database- and memory-backed objects implementing same interfaces (eg.
we've got POFile and DummyPOFile objects) or multiple database-backed
objects implementing same interfaces.  In essence, we've been doing this
but without implementing mock objects for testing as well.  It wouldn't
be too far fetched to go that route, and we can already do it.  Still,
lots of our tests test things that do depend on persistence and
specifics of our data storage (like query-count assertions,
trigger-dependent code, hitting constraints and similar).  Perhaps
that's not really "unit-testing", but I don't want to argue over
semantics: these are some of our most important tests.

While interfaces in Python are mostly a replacement for some other
features of statically compiled languages like Java, I fear that we'd be
structuring our code in a too complex nature:

 Interface -> DAO -> Interface -> Model -> View -> Template

(because eventually, it's going to be hard for us to resist the urge to
treat multiple DAO classes as one 'type')

One can say how this is not overly complex, but then again, we've
already got a lot of confusion with security boundaries, we do a lot of
"mixins", and we also have adapters for Zope "layers", like
TranslationsPerson vs Person.

It has long been agreed that this is the approach to take (i.e. split
model classes by intent as well), which would complicate our code base
even further.  In my opinion, this approach (where you split out all the
code from model classes into "registry", "code", "soyuz",
"translations"... classes) would almost make the need for separate DAO
classes — well, non-existent.  And if the tides are changing and this is
not going to be recommended way to split code out, then we need to think
about the same thing at the same time.

I am not saying it wouldn't be nice to split database model out, I am
just saying that there's a lot more to it that needs to be taken into
consideration before we can call out "victory!".

Cheers,
Danilo