[Zope-dev] relations in objects

[Jason Corbett]

  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 at 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