[Zope3-Users] zalchemy integration

[Jeff Shell]

On 8/14/06, Carlo Cardelli <ccardelli at iv-srl.it> wrote:
>  > I think that my company's recent experiences with Zope and SQLAlchemy
> > show that the fundamentals of Zope can be terrific toolkit for rich
> > object oriented RDBMS / Business Object backed applications that have
> > nothing to do with content management.
>
> Your work seems surprisingly similar to what I want to achieve in the
> long run. Besides, you answered a general question I was thinking to
> post about suitability of Zope for business/no-cm applications.
> At the moment, I am still in a "semi-evaluation" phase, so your
> experience somewhat comforts me :)
>
>  > However, we're also massively behind schedule. This
>  > project we've been working on has involved a lot more engineering than
>  > we foresaw.
>
> This somewhat discomforts me :(

The engineering involved has had more to do with a serious
re-evaluation of business situations than anything else. It's the
'Zope 3' of one of our own long-running applications that had come to
the point where in order to grow to the levels we see it growing to,
it needed to be re-implemented from the ground up. Among other things
we had to implement a deep and fairly rigorous accounting system that
wasn't foreseen. Some things just took a lot more time as we could no
longer take certain things for granted, such as datetimes. I had to
spend a couple of days coming up with some policies, a toolkit, and
some Descriptors, all to ensure that timezone conversion and
application (which didn't matter in our old versions as all times were
local) happened invisibly. This is especially applicable as MySQL
doesn't seem to store timezone information by default. So when we
realized this, and realized its implications as we're set to expand to
more markets, I had to put in the time to ensure datetimes were
accurate and applicable to some different contexts. We just didn't
even think of things like that... Which I think is a burden of the
'Version 3 Rewrite' syndrome: this system has been done twice in the
past, why is it taking so long now? Oh, because Now it's turned into a
real business and there are certain things we really shouldn't 'punt'
on.

And yes, some of that engineering time has been spent at the
framework/toolkit level to ensure that the SQLAlchemy integration is
as smooth as can be expected and that web views are easier to write as
Python classes than Templates and Scripts and that Service level code
(the real business logic) is readable and maintainable by being as
close to english as possible. That last pseudo-requirement came from
maintenance of some older applications where the data abstraction
framework was a bit more crude and the business logic was very hard to
look at. In some cases, there were up to 70 lines of preparation code
that was just loading up different pieces of data and utilities and
other tools just to get a shopping cart ready to check out. So I've
made the point to engineer heavily up front (but based on real
requirements) so that future maintenance is less frightening.

But really, the 'lot more engineering than we foresaw' phrase is a
result of us being our own customers, us foolishly using past
projections and implementations as estimations, and us not really
scoping out ahead of times what it would mean to track money through
the system with 100% reliability, or deal with complex product
offering scenarios that couldn't even be done before.

-- 
Jeff Shell