Roché 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:
me = Student()
zope101 = Course("Introduction to Zope") zope101.current_students.add(me) assert me.current_courses.zope101.name == "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 same 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 for. The goal is this: ZODB needs a reusable model for maintaining complex relationships between database objects. ZODB also needs a basic implementation of that model. The solution must provide developers with ways to create relationships using only a few lines of Python code. The fewer lines the better (but not too few.) Visiting a management interface or writing a configuration file should not be necessary for creating most relationships. This requirement is especially designed to meet the needs of developers inexperienced with ZODB who need an easy way to maintain many-to-many relationships. The solution must provide a very Pythonic way to access and maintain relationships. If you have a SoftwareProject object, for example, you should be able to ask the SoftwareProject for the set of all Developer objects who are working on that project, even though the SoftwareProject does not "contain" the Developers. You should be able to add a Developer to that set and expect any inverse relationships to be updated automatically. The solution must provide a way to make indirect references rather than direct references to ZODB objects. Maintaining complex relationships is important for both simple ZODB applications and Zope applications. In standard ZODB it is often preferable to make direct references to related objects, while Zope 3 requires the ability to maintain relationships using an object hub rather than direct references. It must be possible to implement the solution using either BTrees in a standard ZODB or a relational database. This is designed to allow users to develop applications using a simple FileStorage and deploy using a relational backend such as Ape. The solution must allow complex relationships. A relationship may include metadata. Sean Upton talked about this. The solution must be built on a well-known model for maintaining relationships. If we invent a new model that is hard to map onto any existing model, it will be difficult to know the right way to expand the model as requirements grow. I *think* the solution should allow new relationships to be inferred from existing relationships. For example, if I build an application that assigns students to courses using this solution, I might later need to ask for all courses assigned to a student. Ideally, adding that functionality should not require a database migration step. Do you agree with these requirements and minimal use cases? Is there anything I need to clarify? Shane