[ZODB-Dev] Re: [Zope3-dev] PROPOSAL: ZODB Relationships

[Shane Hathaway]

On Sun, 11 May 2003, Phillip J. Eby wrote:
> All MOF "model elements", including associations and ends, have "name" and
> "annotation" fields.  I just didn't bother expressing them in the made-up
> example.

Ah, ok.  I didn't realize you weren't making a specific proposal.

> >This is the first time I've heard of MOF.  Who is using it?
>
> Well, anybody who uses UML, actually.  MOF is the OMG's metametamodel for
> the UML.  That is, all of the UML constructs are defined in terms of the
> MOF.  UML contains a very large number of complex constructs; MOF contains
> about 26 (give or take a few depending on the version).

So MOF is a language for constructing modeling languages.  I wish the OMG
would explain things in such a simple way.  Thanks.

> >   Maybe I misunderstood MOF, or maybe link metadata isn't important.
>
> If it's attached to an individual link, then by definition it's not
> metadata, it's data - the M0 level.  (OMG specs, including UML, have a
> standard way of referring to various metalevels: M0 is "information", M1
> layer is "model", M2 is "metamodel", M3 is "metametamodel" and so on.)
>
> It sounds, however, like I misunderstood your requirements.  The proposal
> looked like it was pointed at simple symmetric binary associations with no
> link attributes.  Thus, it seemed to me as though the desired functionality
> was in fact a small subset of the metamodel defined by the MOF, so I
> suggested it as a basis for terminology.  That's all.

We chose to leave out the metadata requirements initially to keep the
proposal simple.  It's interesting that by doing this, we learned of a
specification that meets *only* the requirements we stated and little
more.  Perhaps an API that does not support metadata could be useful for
many situations.

> As I've said repeatedly, I'm not advocating that we "use the MOF" in some
> way.  That would be as meaningless as saying we should "use UML" to do
> this.  I'm just suggesting that a lot of work has gone into the MOF specs
> to create a precise model, and it's one that will be easier to read and
> fully understand than the *far* more complex UML specifications.  After
> considerable study, I am at least under the illusion that I have a
> reasonable grasp of MOF.
>
> By contrast, I am under no such illusion that I "understand" the UML
> specification, in the sense of being able to say what a UML diagram should
> translate to in code (viewed from a formal perspective).

Point taken--I feel like I should know UML really well, but a full
understanding consistently eludes me.

> However, if your requirements call for a richer association model, sure, go
> for it.  My inclination, though, is to consider N-ary associations and link
> attributes to be YAGNIs.  I rarely run into an N-ary association (or
> many-to-many association, for that matter) that isn't just as cleanly
> expressed as a set of binary associations.

One of the things I'd like to be able to do is keep the application's view
of an association distinct from the actual structure of the data.  Let's
say I write a simple teacher/course application with a binary association
between teachers and courses.  Later on, I decide that associations
between teachers and courses ought to include information like the date
they started teaching the course.  I don't want to change all of my code
to now connect teachers to registrations to courses.  Instead, I want new
code to be aware of the new information while the old code continues to
work with a simpler view of the database.  In fact, I want some of the new
code to continue using that assumption, since it's simpler.

One way to solve this problem is to add metadata fields when you need to
store more data without changing existing code.  The old code doesn't know
about the metadata, while the new code does.

It just occurred to me that another way to solve this is to use a special
kind of association composed of multiple binary associations.  The special
association would make a complex system of associations look like a
simpler one.  Since this thought just occurred to me, I'm probably not
explaining it well. ;-)

The advantage of the link metadata solution is that it might avoid the
need to migrate databases when associations increase in complexity.  But
it seems like you'll run into trouble if you need to make an association
from metadata.  The second solution might require database migrations, but
since it treats metadata like any other data, associations in metadata
won't add any new complexity.

Shane