[Zope-dev] RFC: RelationAware class for relations betweenobjects

Shane Hathaway shane@zope.com
Wed, 30 Apr 2003 10:53:32 -0400


Roch=E9 Compaan wrote:
> Shane, show us more :-) You've *defined* certain relationships but have
> not shown how to *create* them and how to use them. Will this be
> possible:
>=20
>     me =3D Student()
>=20
>     zope101 =3D Course("Introduction to Zope")
>     zope101.current_students.add(me)
>     assert me.current_courses.zope101.name =3D=3D "Introduction to Zope=
"

That's the kind of thing I was hoping to achieve, yes.

> I think we should make a list of requirements and use cases - at the
> moment it seems as if we are all pointing at a mountain but not the sam=
e
> one. It is difficult to evaluate API's if we don't have requirements.
> I'll try to come up with a list this afternoon.

Now that we've thrown in a few ideas, I think I know what I'm looking=20
for.  The goal is this: ZODB needs a reusable model for maintaining=20
complex relationships between database objects.  ZODB also needs a basic=20
implementation of that model.

The solution must provide developers with ways to create relationships=20
using only a few lines of Python code.  The fewer lines the better (but=20
not too few.)  Visiting a management interface or writing a=20
configuration file should not be necessary for creating most=20
relationships.  This requirement is especially designed to meet the=20
needs of developers inexperienced with ZODB who need an easy way to=20
maintain many-to-many relationships.

The solution must provide a very Pythonic way to access and maintain=20
relationships.  If you have a SoftwareProject object, for example, you=20
should be able to ask the SoftwareProject for the set of all Developer=20
objects who are working on that project, even though the SoftwareProject=20
does not "contain" the Developers.  You should be able to add a=20
Developer to that set and expect any inverse relationships to be updated=20
automatically.

The solution must provide a way to make indirect references rather than=20
direct references to ZODB objects.  Maintaining complex relationships is=20
important for both simple ZODB applications and Zope applications.  In=20
standard ZODB it is often preferable to make direct references to=20
related objects, while Zope 3 requires the ability to maintain=20
relationships using an object hub rather than direct references.

It must be possible to implement the solution using either BTrees in a=20
standard ZODB or a relational database.  This is designed to allow users=20
to develop applications using a simple FileStorage and deploy using a=20
relational backend such as Ape.

The solution must allow complex relationships.  A relationship may=20
include metadata.  Sean Upton talked about this.

The solution must be built on a well-known model for maintaining=20
relationships.  If we invent a new model that is hard to map onto any=20
existing model, it will be difficult to know the right way to expand the=20
model as requirements grow.

I *think* the solution should allow new relationships to be inferred=20
from existing relationships.  For example, if I build an application=20
that assigns students to courses using this solution, I might later need=20
to ask for all courses assigned to a student.  Ideally, adding that=20
functionality should not require a database migration step.

Do you agree with these requirements and minimal use cases?  Is there=20
anything I need to clarify?

Shane