[Zope] ObjectManager example needed

[Dylan Reinhardt]

On Sun, 2003-11-23 at 17:39, Paul Howell wrote:
> At 02:14 PM 11/23/2003 -0800, Dylan Reinhardt wrote:

> >The Verdi object would then have a "pieces" property of [Aida, Otello]
> >and each of Verdi's operas has a "composers" property of [Verdi].
> 
> While this is a straightforward M:N approach, it is not recommended for 
> most applications because each piece of information is recorded twice, not 
> once.  

An excellent point.  If that's important to you, you could record it in
only one place and the object hierarchy is still a good way to model
this data.  

But a little redundancy *can* be a good thing in this domain, so long as
it's managed well.  In web apps, you often drill into data in arbitrary
ways.  Why should it be cheap to know who wrote Aida but expensive to
know what else Verdi wrote?

What's critical here is having *one* way of creating & changing the
data.  So, for example, you can create and edit composer objects
independently, but can only assign composers to pieces in the piece
management screens.

That said, it may be best to think of each piece object as a large
mapping for composer, artist, etc. Objects.  If that streamlines
development substantially, the extra cycles are well spent.


> Fact: Verdi wrote Aida.  This fact should be recorded only once, not 
> twice in two different places.

More generally, you should have exactly one *process* for creating and
maintaining each bit of data.  There are any number of reasons one might
choose to allow some redundancy in how data is accessed.


>   This is standard practice when developing 
> SQL database applications

Understood.  Zope at its best works almost nothing like an RDBMS.  


> My leaning is toward Dennis's suggestion... use SQL.  It seems a 
> straightforward application there.  Best wishes...

You could certainly do that.  If an RDBMS is the tool you're most
familiar and comfortable with, that's probably the best solution for
you.  But this is *exactly* the area, IMO, where ZODB shows more power,
intuition, and flexibility than SQL.

It's not hard to understand why LAMP became the dominant method of
creating web apps: it leveraged existing skills and assets.  But Zope
reflects much of what's been learned about web apps *after* LAMP caught
on.  You *can* use Zope as a high-octane PHP, but Zope is also capable
of managing data in new and more interesting ways.  

If you're more comfortable with RDBMS/LAMP development, use that.  But
know that there is also value to breaking that mold.

FWIW,

Dylan