[TransWarp] Transactionality and enterprise politics (was Re: Tips on using model, storage, config, and naming)

[Phillip J. Eby]

At 01:20 PM 12/30/02 +0200, Roché Compaan wrote:

>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.

We all are.  I've been programming professionally for just shy of 20 years 
now, and I'm continually learning new things.  Not just environments or 
APIs or tools, which of course are always a constant learning issue, but 
new ways of looking at things, new ways of doing things at the higher 
levels of design patterns, architecture patterns, process patterns, and so on.


>  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.

Exactly.



>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?

But how much does it cost you to create that middleware?  And more to the 
point, what does it gain you?  If you chose MySQL for speed, adding a 
middleware layer to do that stuff is just going to slow it down.  Why not 
just use a reasonably fast DB in the first place?

As for Cygwin performance, the main issue to watch out for is memory 
consumption of anything that does 'fork()'.  Windows doesn't do fork, so 
Cygwin emulates it by copying the entire app's memory contents at fork 
time.  The next thing to watch out for would be filesystem performance.

But I do have a question for you...  do you need to run a multi-user server 
from a Windows machine?  If all you need is a local database, you might be 
better off with something like SQLite.  While it lacks referential 
integrity and uses "everything's a string" data types, it does have 
transactions, and it stores an entire database in a single file, which is 
more convenient for single-user applications.


>Before I started using MySQL, I used
>Interbase/Firebird but it was really unstable on linux. So, what are my
>options?

To be honest, it has been at least 5 years since I seriously considered a 
Windows machine a suitable basis for any kind of multi-user application 
server, so the cross platform issue hit a blind spot for me here.  My 
emphasis on Windows support in PEAK has been primarily intended for client 
applications, and I didn't even know that MySQL *ran* on Windows.


>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?

It would depend on the circumstances.  If the discussion was private and I 
thought they were salvageable, I'd probably go down the education route, 
starting by asking them why they believe private methods enhance security 
in any way.  If the discussion were public and I knew they were just trying 
to score points, I'd go on the attack by pointing out that languages with 
built-in security put your safety in the hands of a possibly malicious 
third party, who may or may not have done their job well in any case, and 
provide you with no way to verify that your code is safe.  But, if a tool 
claims to be secure, this encourages programmers to be lazy and not check 
whether the code they write is introducing a security hole that a hacker 
can exploit.  Further, the history of security holes in Java VMs to date 
suggests that it is very hard to get a machine to do a human's job of due 
diligence where security is required.  It is very important, therefore, to 
choose your developers wisely, because the true security of the company 
depends on the people who work there.

Key points there:

1) a machine can't do a human's job - this plays well with that part of the 
audience that fears computers

2) technology X makes the programmers lazy and not do their jobs - this 
plays well to the part of the audience that suspects programmers are lazy 
goof-offs but are annoyed that they can't prove it because they don't know 
enough about what programmers do.

3) those darn hackers and malicious programmers!

4) we, your humble developers, are your true treasure.  This is to remind 
our supporters of everything we've done for them in the past, and encourage 
them to jump in on the side of truth and justice now.  :)

You'll notice that none of this has anything to do with what technology 
would actually be useful or relevant to the business' goals.  Such is the 
politics of enterprise application development sometimes.

People who are actually arguing for or against a technology for *technical* 
reasons, or who have only technical arguments to support their political 
goals, are actually quite easy to deal with if you know what you're 
doing.  It's the people who use *political* arguments to achieve their 
goals that you really have to watch out for.  The really nasty ones can tie 
you up for weeks or months defending against their maneuvers.  :(


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

We don't perform transactional operations against LDAP; we use it as a 
directory service only, so atomic operations suffice.  We do in fact use 
OpenLDAP, although we have a Netscape server as a central repository for 
pushing to OpenLDAP replicas on each machine that needs access to the 
directory.