[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