[TransWarp] Tips on using model, storage, config, and naming (was Re: First attempt to use the storage package in PEAK)

[Roché Compaan]

On Sun, 29 Dec 2002 21:29:14 -0500
"Phillip J. Eby" <pje at telecommunity.com> wrote:
> > > >I've attached the mysql driver if you want to include it - it was
> > > >fairly simple to write since MySQLdb implements the DB API.
> > >
> > > I'm afraid MySQL gives Ty and I the creeps, and we don't feel comfortable
> > > including a driver for it with PEAK for a number of reasons.  Because 
> > we do
> > > try to "think of everything", we are concerned about its locking and
> > > transactional semantics and how they would interact with PEAK's caching,
> > > locking, and transactional patterns.  We couldn't say whether or not it
> > > will work correctly, and so are totally uncomfortable including it in an
> > > "enterprise application kit".
> >
> >Given the amount of effort that went into its transactional capabilities
> >that was recently added, I think you owe it at least some benchmarks.
> 
> It's the recency of the adding that bothers me.  Transactions are hard to 
> do correctly.  Repeat after me: transactions are hard to do correctly.

Yes, transactions are hard to do. I must admit that I neglected how
important they are for far to long :-(

> > > In the environment where I work, *PostgreSQL* is considered a lightweight
> > > database for prototyping purposes, and Sybase or Oracle are what you use
> > > for production applications.  One of our apps has a 30GB database on a 
> > RAID
> > > array, and its dedicated database server hardware is a 64-bit,
> > > four-processor machine, with an identical warm standby server continuously
> > > replicated from the first.  PEAK really is intended to work at this 
> > sort of
> > > "enterprise" scale, and using MySQL for production in such an environment
> > > would be quite insane, IMO.
> >
> >Huh? Sure it's supposed to work at that scale but you will certainly not
> >make an environment like this a requirement in the readme.
> 
> I won't?  Darn.  ;)  Just kidding.
> 
> 
> >As far as I
> >can see, PEAK aims to provide way more than just robustness and
> >scalability.
> 
> Yes.  It also aims at saving developers from themselves, within 
> reason.  Failing that, I *strongly* prefer that a developer avoid or 
> abandon PEAK because it's too "hard", than that they "easily" shoot 
> themselves in the foot.  I "easily" shot myself in the foot at times with 
> both the early versions of Zope, and even with my own framework 
> ZPatterns.  In both Zope and ZPatterns, design decisions were made that 
> favored ease, transparency, and "do what I mean"-ishness over robust 
> applications, where "robust" is defined as "easy to maintain and debug".

I don't have a degree in computer science and have relied on books, the
open source community and the frameworks I use to teach me about good,
and too often, bad design. I realised that it takes a very long time to
really get to know a programming environment so well that you can call
yourself experienced - I'm still doing my apprenticeship. In the process
of learning a chosen environment and navigating through so many levels
of abstraction one tends to be lead into doing things in a way that
"fits" the framework.

I started out with Delphi, about 7 years ago and there was absolutely
nothing in the IDE that encouraged good separation of UI, application
logic and backend and its main concern was ease of use no matter what
the cost, _definitely_ not ease of maintenance. I am not saying that you
can't implement a good design in Delphi - it just didn't make it easy to
do so. So my first big lesson was separation of church and state and
then I started to dream of applications that are actually maintainable.

I moved on to Zope and Python about 3 years ago and although I managed
to achieve some degree of separation in my code I still didn't end up
with applications that are easy to maintain, basically for reasons we
already touched on in this thread like configuration management, 3rd
party customisation, etc. My other big problem with Zope is that it
seduced me into coding apps in ways that left me without the support of
all the tools one has when coding on the filesystem. I recently wrote a
tool to serialise permissions, proxy roles, properties and source to the
filesystem and synchronise it back to the ZODB just to be able to check
in the complete state of an application into CVS.

I mention all this because:
    
    - I appreciate the fact that PEAK tries to protect the developer
      against himself.

    - I appreciate the fact that you are concerned about technologies
      that may corrupt good design principles.

I was caught by surprise with your comments on MySQL and am now
seriously re-evaluating :-) I don't for one minute think MySQL is all
there is to databases - I am *very* aware of its limitations. At the
moment it provides me with a reasonably stable and affordable database
on Linux and Windows whereas Postgres needs to run in a Cygwin
environment on Windows and I don't now how this will affect its
performance. I also thought that MySQL's lack of referential integrity
and transactions is ok as long as their is a layer or middleware above
it that takes care of it? Before I started using MySQL, I used
Interbase/Firebird but it was really unstable on linux. So, what are my
options?

> >For one, it provides a serious developer with a framework
> >that heeds to proven software design patterns. There are even very small
> >apps that can benefit from PEAK from a design point of view.
> 
> Oh, most certainly.  Even system administration scripts can use PEAK usefully.
> 
> 
> > > So, while I'm sure that you would never use it for an application
> > > environment it wasn't suited for, I'm not comfortable with making any
> > > implication that PEAK supports or endorses its use in any way, because
> > > PEAK's intended audience *does* include people who would abuse MySQL, and
> > > in the process would give other people an excuse to trash PEAK, Python, 
> > and
> > > Open Source in general for their lack of attention to "enterprise-level"
> > > concerns.
> >
> >My guess is that the type of people you describe will steer right past
> >PEAK and click away in their decorated build-it-in-a-day IDE's.
> 
> You miss my point; I'm saying that "enterprise application development" is 
> an extremely *political* endeavor.  It's not that the person who would hold 
> that opinion might ever use PEAK, it's that they might use MySQL as a 
> weapon to discredit someone who *did* want to use PEAK in that organization.
> 
> Let's just say I've had some experience of this sort of political 
> infighting before, and leave it at that.  :)

How would you respond to people saying that Python is not suited for
enterprise applications because it has no proper security built in, in
that it has no sence of private and public methods?

What implementation of LDAP are you using? I ask because OpenLDAP does not
currently support transactions?

-- 
Roché Compaan
Upfront Systems                 http://www.upfrontsystems.co.za