I'm sorry for my ignorant use of the terms relation and relationship. I'll try to use the terms more appropriately in the future. I think I understand where I've become confused. In many of the persistance mechanisms I've looked at references to other objects were handled specially, and had rules associated with them. I think I understand now that it is mearly just a design problem, nothing having to do with zope. When creating objects I will need to pass the reference to the other object, or have a manager for the relationship. I had assumed that objects were somehow self aware in some way of the zope environment, and therefore coule access it. I appologize for any time I might have wasted. The solution is simpler than I had thought. Jason Corbett --- Leonardo Rochael Almeida <leo@hiper.com.br> wrote:
On Fri, 2003-10-10 at 00:46, Jason Corbett wrote:
Thanks for your reply. I've actually been thinking in an object oriented form for a while. I've looked at implimenting this project in Java using either prevailance or a object persistence model that mapped to a RDBMS. I like the idea of zope, so maybe I should clarify my question:
How does an object in zope know where it sits in the hirearchy, and how does it reach other objects. That's what I'm really looking for, I can probably code the rest of the parts.
In my experience, you should put an object inside another if and only if they have an explicit containment relationship, e.g. a car has 4 tires and a steering wheel. The steering wheel can belong to (at most) one car at any moment in time, so it would make sense to put the steering wheel object inside the car object. The same is not true of, for instance, students and school classes. In this case you either store a reference to the student in the school class (eg a student id in a "lines" or "tokens" property) or you create an object to represent the class-student relationship (for example an enrollment) and store it somewhere.
Tip: always use methods that return the objects you need, for instance aSchoolClass.students() this way you can more easily change the storage of the relationship information when you change your mind. And you will change your mind a lot of times.
Tip2: a lot of times you'll implement the above mentioned methods as catalog queries, like: what objects in the other side of the relationship reference me?
Tip3: look mxmRelations
Cheers, Leo
PS: just because this is a pet peeve of mine, I'll explain that a "relation" and a "relationship" are two very different things. "Relation" is the mathematical term for a table, a set of distinct elements (rows) with the same kinds of attributes (columns). You can think of a relation (table) of cars, or a relation (table) of students. Relational databases get their names because they store relations and allow you to do some relational algebra with (usually) SQL.
A relationship, on the other hand, is a link, or association, between elements.
RDBs allow you to model relationships relatively easily thru either relational operations:
SELECT * from cars, steering_wheels WHERE steering_wheels.carId = car.carId AND steering_wheels.wheelType = "sport"
or by storing relationship information in relations (sometimes known as "link relations" or "link tables"):
SELECT * from enrollments, classes, students WHERE classes.classId = enrollments.classId AND enrollments.studentId = students.studentId AND students.studentName = "Jason Corbett"
But RDBs themselves have absolutely no concept of "relationships".
So, next time you read the word "relation", think "table" :-)
__________________________________ Do you Yahoo!? The New Yahoo! Shopping - with improved product search http://shopping.yahoo.com